The OWASP Top 10 is the industry’s shared list of the risks that actually cause breaches. Laravel already defends against most of them, but a framework can only protect the code paths you let it protect. This guide walks the Top 10 and shows, for each, where Laravel has your back by default and where a single line of code opens the door again.
It is one of the deeper guides on the Laravel Security Review hub. For a faster pass, the production checklist covers the same ground as actions.
A01 Broken Access Control
The number one risk, and the one Laravel cannot solve for you. Authenticating a user does not authorize an action. Use Policies and call authorize() on every action that touches a specific record:
$this->authorize('update', $post); // 403 unless this user owns this postThe full treatment is in Securing Authentication and Authorization in Laravel.
A02 Cryptographic Failures
Laravel encrypts cookies and gives you the Crypt facade and the encrypted cast for data at rest. The failures are around it: a missing or shared APP_KEY, secrets committed to the repository, or sensitive traffic served over HTTP. Force HTTPS and keep .env out of version control.
A03 Injection
Eloquent and the query builder use bound parameters, so ordinary Laravel code is safe from SQL injection. Injection returns the moment you build raw SQL from user input:
// Vulnerable
User::whereRaw("email = '{$request->email}'")->first();
// Safe
User::whereRaw('email = ?', [$request->email])->first();The same rule applies to DB::raw() and orderByRaw(): pass user input as a binding, never as string text.
A04 Insecure Design
Some flaws are in the plan, not the code. A password-reset flow that reveals whether an email exists, or a checkout that trusts a price sent from the browser, is insecure by design. Validate on the server, derive values like prices from the database, and think through the abuse cases before writing the feature.
A05 Security Misconfiguration
The most common real-world entry point. APP_DEBUG=true in production leaks stack traces and environment variables to anyone who triggers an error. Confirm debug is off, run config:cache, remove unused packages, and make sure .env and .git are not reachable over the web.
A06 Vulnerable and Outdated Components
Most compromises enter through an unpatched package rather than custom code. Make dependency auditing part of every release:
composer auditApply security releases quickly. The gap between a patch being published and being applied is exactly the window attackers scan for.
A07 Identification and Authentication Failures
Weak passwords, no rate limiting on login, and no protection for stolen sessions. Enforce strength with the Password::min(12)->uncompromised() rule, throttle login routes, regenerate the session on login, and offer two-factor. The token concept underpins how sessions and CSRF tokens keep an authenticated identity honest.
A08 Software and Data Integrity Failures
This covers unsafe deserialization and untrusted code. In Laravel terms: never unserialize() user input, verify webhook signatures before trusting a payload, and pin and verify your dependencies rather than pulling unreviewed updates into production automatically.
A09 Security Logging and Monitoring Failures
You cannot respond to what you cannot see. Log authentication events, authorization denials and important state changes. Send logs somewhere durable, scrub secrets before writing them, and make sure someone or something actually reads them. An unread log is not monitoring.
A10 Server-Side Request Forgery
If your app fetches a URL supplied by a user, for example to import an image or call a webhook, an attacker can point it at your internal network or cloud metadata endpoint. Validate the host against an allow-list, reject private and link-local address ranges, and never send the raw response back to the user.
Two risks Laravel handles well by default
Cross-site scripting: Blade escapes output with {{ }}, so XSS mainly returns through {!! !!} and unescaped HTML attributes. Cross-site request forgery: the web middleware verifies a CSRF token on every state-changing request, as long as you include @csrf in forms and do not exempt routes carelessly. Both are covered further in 7 Laravel features to enhance the security of your application. File uploads, which appear under several of these categories, build on the fundamentals in file upload handling in PHP.
Related
- Laravel Security Review: a practical walk through reviewing and hardening a Laravel application, area by area, with every guide in this cluster in one place.
- A Laravel Security Checklist for Production
- Securing Authentication and Authorization in Laravel
- 7 Laravel Features to Enhance the Security of Your Application
- Why do we use a token concept in PHP?
