Laravel Security Checklist for Production

Laravel includes strong security defaults, such as CSRF protection, password hashing, parameter binding and Blade output escaping, but production safety depends on configuration and how the application uses them. Before launch, check at minimum: debug mode off, secrets out of the repository, validation on every input, explicit authorisation on every action, safe file uploads, secure session settings, current dependencies, and logs that do not leak sensitive data.

1. Environment and configuration

• APP_ENV=production and APP_DEBUG=false. Debug mode shows stack traces, environment details and sometimes secrets.
• APP_KEY is set, unique per environment, and never committed.
• .env is not in version control and is not reachable from the web (the document root must be public/, not the project root).
• Run php artisan config:cache and route:cache in deployment, and keep config values coming from the environment.

2. Secrets

• Database passwords, API keys and mail credentials live in environment variables or a secrets manager.
• Each environment uses different credentials.
• Secrets are rotated after staff changes or suspected exposure.
• Secrets are never logged.

3. Validation and mass assignment

• Every request is validated (Form Requests or $request->validate()), including types, lengths and allowed values.
• Models use $fillable (or carefully reviewed $guarded) so users cannot set fields like is_admin or user_id.
• Only validated data is passed to models: use $request->validated().

4. Authorisation

• Every controller action checks permissions with policies or gates ($this->authorize(), can middleware).
• Records are looked up within the user's scope (for example $user->orders()->findOrFail($id)) to prevent one user reading another's data.
• Admin routes are protected by role checks, not just hidden URLs.
• Tests cover "user A cannot access user B's record".

See API security basics and OWASP Top 10 explained.

5. Injection and output

• Use Eloquent or the query builder with bindings; avoid raw SQL built from user input. If DB::raw or whereRaw is needed, bind parameters.
• Blade's {{ }} escapes output; use {!! !!} only for trusted, sanitised HTML.
• Sanitise any user-supplied HTML (for example rich text) with a proven library before storing or displaying it.

6. CSRF and sessions

• CSRF middleware is active for web routes; forms include @csrf.
• Exceptions to CSRF (webhooks) verify signatures instead.
• SESSION_SECURE_COOKIE=true, http_only true, and a deliberate same_site value. See secure cookies explained.
• Session IDs are regenerated on login (Laravel's authentication does this).

7. Authentication

• Use Laravel's authentication scaffolding or a maintained package rather than custom crypto.
• Rate-limit login and password-reset routes (throttle middleware).
• Offer or require two-factor authentication for admin users.
• Passwords are hashed with the framework's hasher, never stored or logged in plain text.

8. File uploads

• Validate file type (by content and extension), size and count.
• Store uploads outside the public directory or on a disk that never executes them; serve them through controlled routes if they are private.
• Generate new file names; never trust the client's file name or path.

9. HTTP and transport

• HTTPS everywhere, with HSTS once stable.
• Security headers set (CSP, X-Content-Type-Options, Referrer-Policy, frame protection); see HTTP security headers explained.
• TrustProxies configured correctly behind a load balancer or CDN, trusting only your real proxies (otherwise users can spoof their IP address with forwarded headers).
• CORS limited to the origins you need.

10. Dependencies

• Laravel and PHP are on supported versions.
• composer audit and npm audit run regularly or in CI.
• Unused packages are removed.

11. Logging and monitoring

• Errors are logged and alerted on, without passwords, tokens or full card data.
• Logs are protected and rotated.
• Authentication and authorisation failures are monitored for unusual spikes.

12. Queues, scheduler and storage

• Queue workers and the scheduler run under a non-root user.
• Redis, the database and queues are not exposed to the internet.
• Backups of the database and uploaded files are automated and tested. See server backup strategy.

Example: a pre-release security review in one hour

Before each significant release, a small team runs through this short review:

1. Configuration: php artisan about on production shows the environment, debug status and cache state; confirm debug is off.
2. Routes: php artisan route:list — look for new routes without the expected middleware (auth, throttle, permission checks).
3. Authorisation tests: run the test suite, including tests that try to access other users' records.
4. Dependencies: composer audit and npm audit; update anything with known vulnerabilities.
5. New uploads or file handling: check validation, storage location and filenames.
6. New integrations: confirm webhook signatures are verified and secrets come from the environment.
7. Logs: make sure new code does not log personal data, tokens or passwords.

Most of these checks take minutes and catch the mistakes that matter most.

Example: protecting a sensitive action

Changing an account's email address is a common takeover step. A safer implementation:

• requires the user to re-enter their password (or confirm with 2FA) before the change;
• sends a notification to the old address with a way to report it;
• requires verification of the new address before it takes effect;
• is rate-limited and logged.

Laravel provides building blocks for each step (password confirmation middleware, notifications, signed URLs, rate limiting); the security comes from using them together.

Frequently Asked Questions

Is Laravel secure by default?

Its defaults are good, but defaults cannot cover authorisation logic, configuration mistakes or unsafe custom code. This checklist targets those gaps.

What is the most common serious mistake?

Missing object-level authorisation: allowing users to access records by ID without checking ownership.

How often should we review security?

Before each major release, after adding new features that handle sensitive data, and at least a few times a year.

Related reading

See Laravel for business applications and website security basics. For Laravel applications built and maintained by a team, see ServerNeed custom web development.

Sources

• Laravel documentation
• OWASP Laravel Cheat Sheet