Over the past few years patching security issues on live client sites, I've noticed the same handful of gaps show up again and again — almost never anything exotic, usually just a default left unchanged or a check skipped under deadline pressure. This is the checklist I run through before any Laravel app goes live.
1. Lock down your environment file
Your .env file should never be reachable from the browser and should never be committed to version control. Confirm APP_DEBUG is set to false in production — a stray stack trace on a live error page can hand an attacker your database credentials and file paths without them lifting a finger.
2. Validate and sanitize every input
Laravel's form request validation makes this easy to get right, so there's rarely a good excuse to skip it. Validate on the way in, and use Eloquent or query bindings rather than raw queries to avoid SQL injection. Escape output in Blade templates by default, and be deliberate about the rare cases where you use unescaped output.
3. Keep dependencies current
Run composer audit regularly and subscribe to security advisories for any packages handling authentication, payments, or file uploads. A surprising number of the vulnerabilities I've patched traced back to an outdated package rather than custom code.
4. Harden authentication and sessions
Use Laravel's built-in hashing (bcrypt or argon2) — never roll your own. Set sensible session lifetimes, enable HTTPS-only cookies, and add rate limiting to login and password-reset routes so they can't be brute-forced.
5. Enforce HTTPS and security headers
Force HTTPS in production and add headers like Content-Security-Policy, X-Frame-Options, and X-Content-Type-Options. These are a few lines of middleware that close off a surprising number of common attack vectors.
6. Apply least-privilege database access
Your application's database user should only have the permissions it actually needs. If it doesn't run migrations in production, it doesn't need schema-altering privileges. This limits the blast radius if application-level access is ever compromised.
7. Log and monitor
Set up logging for failed login attempts and unusual activity, and make sure someone actually looks at those logs. The fastest way to limit damage from an incident is knowing about it quickly.
None of this is exotic — it's mostly discipline applied consistently before launch. If you'd like a second pair of eyes on a Laravel app before it goes live, that's exactly the kind of work I take on.