Laravel security checklist for 2026

Laravel gives you a secure starting point. It protects against cross-site request forgery, escapes output in Blade templates, uses prepared statements for database queries and hashes passwords properly. Most Laravel applications that get breached are not let down by the framework. They are let down by something the application itself does, or forgets to do.

This is the checklist we start from in our security reviews. It is not exhaustive, but if you can tick every item you will have closed the gaps we find most often.

Versions and patching

• Laravel is on a supported version. As of October 2026, Laravel 13 is fully supported and Laravel 12 receives security fixes until 24 February 2027. Laravel 11 and older no longer receive security fixes. See our version support tracker.
• PHP is on a supported version. PHP 8.1 is out of support, and PHP 8.2 reaches the end of security support on 31 December 2026.
• Dependencies are audited. Run composer audit and npm audit regularly, and in CI. Our guide to patching Laravel dependencies explains a routine that works.

Authentication

• Use a first-party starter kit or package for login, registration and password resets rather than custom code.
• Rate-limit login and password reset routes. Laravel's rate limiter makes this a few lines of code.
• Offer or require two-factor authentication for admin accounts and anyone with access to sensitive data.
• Expire sessions sensibly, and invalidate other sessions when a password changes.

Authorisation

This is where we find the most serious issues.

• Every action checks permission, not just login. Use policies and call them in controllers, form requests or Livewire components. Being logged in is not the same as being allowed.
• Every query is scoped to the right owner. In multi-tenant apps, a user should never be able to load another tenant's record by changing an ID in the URL.
• Admin routes are protected by both authentication and an explicit role or permission check.
• API endpoints have the same checks as the web pages that use them.

Input and output

• Validate everything with form requests, including data from your own front end and from webhooks.
• Guard against mass assignment. Define $fillable on models, and never pass $request->all() straight into create() or update().
• Be careful with raw queries. DB::raw(), whereRaw() and orderByRaw() with user input are injection risks. Use bindings.
• Avoid unescaped output. Treat every {!! !!} in a Blade template as something to justify.
• Restrict file uploads by type and size, store them outside the public folder and serve them through a controller that checks permission.

Secrets and configuration

• APP_DEBUG is false in production. Debug pages expose environment variables, including your keys.
• The .env file is not in Git and is not reachable from the web.
• Secrets are rotated when a developer or supplier leaves, and after any suspected leak.
• Each environment has its own keys, so a leaked staging key cannot touch production.
• APP_KEY is unique per environment and never shared.

HTTP and browser security

• HTTPS everywhere, with HSTS enabled.
• Security headers are set, including a Content Security Policy, X-Content-Type-Options, Referrer-Policy and a frame policy.
• Cookies are secure. Session cookies should be Secure, HttpOnly and have a suitable SameSite setting.
• CORS is restricted to the origins that need it.

Servers and infrastructure

• The operating system is patched automatically or on a schedule.
• SSH uses keys, not passwords, and root login is disabled.
• Only the ports you need are open. Databases and Redis should not be reachable from the internet.
• Backups are encrypted, stored off the server and tested.
• Access is reviewed. Remove former staff and suppliers from servers, Git hosting, DNS and third-party dashboards.

Our infrastructure management service covers this layer.

Monitoring and response

• Errors are tracked, so unusual failures are spotted quickly.
• Important events are logged, such as logins, permission changes and exports, without logging passwords or full card numbers.
• You know who to call. Have a short written plan for what happens if you suspect a breach, including how to meet the ICO's 72-hour reporting window for personal data breaches.

Getting help

If working through this list raised more questions than it answered, our security review covers all of it and more, with a written report, a free retest once fixes are in and the option of a monthly patching plan afterwards.