Laravel Security Checklist: 15 Checks Before You Ship
Laravel is secure by default — your configuration usually isn't. This 15-point checklist covers the exposure classes we actually find when scanning Laravel apps in production.
Laravel ships with strong defaults: Eloquent parameter binding, CSRF middleware, hashed passwords, signed URLs. And yet Laravel applications keep getting breached — almost never because of the framework, almost always because of configuration, deployment, and the code written around it. This checklist covers the fifteen exposure classes we actually encounter when scanning Laravel applications in production, with the fix for each.
Application Configuration
1. APP_DEBUG in production
The single most common critical finding on Laravel properties. With debug mode on, any error renders a full stack trace, environment variables (database credentials, mail secrets, API keys), and file paths. An exposed .env on disk plus APP_DEBUG=true is effectively total credential disclosure. Fix: APP_DEBUG=false in production, verified in deployment — not just at initial launch.
2. .env and dotfiles reachable over HTTP
A web server misconfiguration that serves the project root lets anyone download .env directly. Every credential inside — database, Redis, mail, Stripe, cloud keys — is compromised in one request. Fix: deny access to dotfiles at the server level (both nginx and Apache patterns are one-liners), and never place the application root inside the public web path.
3. Framework debug tooling left public
Telescope, Ignition, Horizon dashboards, and similar tooling default to convenient access controls — and in production are frequently reachable without authentication. Each is an information-disclosure goldmine (queries, jobs, environment data). Fix: gate them behind authentication middleware or restrict by IP; disable outright if unused.
Input and Data Handling
4. Raw query building
Laravel's query builder and Eloquent protect against SQL injection when you use parameter binding. The escape hatch is DB::raw(), whereRaw(), and string interpolation into queries — anywhere user input is concatenated, injection returns. Fix: bindings everywhere (whereRaw('col = ?', [$value])), and treat any DB::select("... $var ...") as a finding by definition.
5. Mass assignment gaps
$request->all() feeding a model without a $fillable allowlist is the classic escalation path: add is_admin to the request payload and become an administrator. Fix: explicit $fillable on every model, $request->only([...]) at every write site, and treat unguard as never.
6. File upload validation
Weak upload rules (extension checks only, MIME trust from the client, storage inside the public root) become webshell deployments. Fix: validate by extension allowlist and content, generate server-side filenames, and store uploads outside the web root or on object storage.
7. Unvalidated redirects and file inclusions
redirect($request->input('next')) and dynamic view()/include() paths from user input are open redirect and local file inclusion primitives respectively. Fix: allowlist redirect targets; never let user input select file paths.
Session, Auth and Headers
8. Cookie and session hardening
Verify SameSite=Lax (or Strict), Secure, and HttpOnly on session cookies, and short-enough lifetimes for your risk model. These three attributes close entire attack classes (CSRF-by-cookie, theft-over-HTTP, XSS credential capture).
9. Security headers
Laravel does not set most security headers by default. A production application should send: Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options: nosniff, X-Frame-Options/frame-ancestors, and Referrer-Policy. Fix: middleware that sets them on every HTML response — five lines of code covering five finding classes. (Our security headers guide covers each header in depth.)
10. CSRF coverage on state-changing routes
Laravel's CSRF middleware covers POST routes in the web group — but API routes (api group), webhook handlers, and any route moved outside the middleware group silently lose protection. Fix: audit state-changing endpoints for token enforcement, especially those accepting API or webhook traffic.
Deployment and Exposure
11. Backup and archive files on the web root
site.tar.gz, backup.zip, .sql dumps, and editor swap files in the public directory — deployment artifacts that hand over source code and databases in a single download. Fix: deploy artifacts never live in the public root; automated cleanup after each release; the scanner's backup-file discovery check verifies the class is closed.
12. Directory listing and open directories
storage/, cache/, or the project root served with autoindex on. Low-tech, high-yield. Fix: disable directory indexing, and verify with an open-directory scan.
13. Vendor and composer artifacts
vendor/, composer.lock, and package-lock.json reachable over HTTP disclose your exact dependency graph — a reconnaissance gift that lets attackers skip fingerprinting. Fix: serve only the public/ directory (the intended Laravel deployment shape) and block direct access to everything else.
14. Queue and Redis exposure
Redis without auth on a routable interface, Horizon dashboard public, queue workers with broad permissions — the infrastructure around Laravel is scanned as eagerly as the application itself. Fix: private binding, authentication, dashboard gating.
15. Dependency currency
Laravel itself and every package in composer.lock needs patch tracking. The framework ecosystem moves fast, and long-running Laravel apps frequently pin versions that are multiple security releases behind. Fix: scheduled composer audit, plus continuous dependency scanning — because new advisories appear against versions you shipped months ago.
Verify the Checklist Automatically
Every item above maps to scanner checks in the 2MNY engine — the Laravel Security Suite and PHP Hygiene & Framework Debug Suite cover Laravel-specific exposure, alongside the generic backup-file, open-directory, secret-scanning, and dependency modules. Run a free scan against your staging or production property, review the full 232-scanner list, or self-host the open-source core (Laravel itself — fittingly) from GitHub.
Related reading: Open-Source Web Vulnerability Scanners in 2026 · Supply-Chain Dependency Vulnerabilities · Security Headers Explained
1 Is Laravel secure by default?
Laravel ships with strong defaults — prepared statements via Eloquent, CSRF middleware, encrypted sessions, and blade escaping. Most Laravel vulnerabilities come from what developers add: raw query methods, unvalidated requests, mass-assignment without fillable locks, and exposed debug mode (APP_DEBUG=true) in production.
2 What are the most common Laravel security mistakes?
The recurring ones: leaving APP_DEBUG on in production (leaks stack traces and credentials), using whereRaw/orderByRaw with user input, skipping validation, forgetting $fillable/$guarded on models, exposing .env and storage paths, and running outdated versions with known CVEs. The 15-point checklist in this article covers each with the fix.
3 How do I check my Laravel app for vulnerabilities?
Run a deep scan — 2MNY includes a dedicated Laravel fingerprinting and hygiene suite that detects the framework, checks debug-mode exposure, config and backup file exposure, session and cookie flags, and known-vulnerable package versions. You get a prioritized report you can hand straight to your developers.
4 Does Laravel's CSRF protection cover everything?
It covers state-changing web form requests via the VerifyCsrfToken middleware, but not API routes (token-authenticated by design), webhooks (external callers cannot hold your token — validate signatures instead), and any route you exclude in the $except array. Those exclusions are a classic silent hole worth auditing.
