Web application security in Laravel: from OWASP to production operations

Why most web applications ship with known vulnerabilities

A fresh Laravel installation handles a surprising amount of security out of the box. CSRF tokens on every form. Bcrypt password hashing. Parameterised queries through Eloquent. Blade template escaping. These defaults cover the basics, and many developers stop there.

The problem is that defaults protect against the common case, not your specific case. A raw database query bypasses Eloquent's parameterisation. An {!! $html !!} directive in Blade disables escaping. A misconfigured CORS policy opens the API to cross-origin abuse. Every Laravel project we audit has at least one place where a developer stepped outside the framework's safety rails without adding compensating controls.

How Laravel handles the OWASP Top 10

The OWASP Top 10 catalogues the most critical web application security risks. Laravel addresses most of them through framework conventions, but each requires deliberate application. The principle of defence in depth applies throughout: no single control is sufficient, and every layer assumes the layer above it has failed.

The first three categories account for the majority of vulnerabilities we find in inherited codebases. They are all application-level concerns where the framework provides strong defaults that developers routinely bypass.

Authentication and authorisation patterns that survive production

Authentication is identity: proving who someone is. Authorisation is permission: controlling what they can do. Conflating the two is the most common architectural mistake we fix in inherited codebases.

Authentication

Laravel ships with Sanctum for SPA and mobile token authentication, and supports Passport for full OAuth 2.0 flows. For most business applications, Sanctum with session-based authentication is sufficient and simpler to reason about.

Password policy matters more than password complexity. We enforce minimum length (12 characters), check against the HaveIBeenPwned breached password database using Laravel's Password::uncompromised() rule, and implement progressive delays after failed login attempts. TOTP-based multi-factor authentication (using packages like pragmarx/google2fa-laravel) is standard on any application handling financial or personal data.

Authorisation

Laravel's Gate and Policy system is well designed but under-used. We define policies for every Eloquent model and register them in AuthServiceProvider. The critical pattern: always authorise at both the route level (middleware) and the query level (scoped queries). Route-level authorisation prevents access to endpoints. Query-level authorisation prevents data leakage through parameter manipulation.

In multi-tenant applications, query scoping becomes even more critical. Every database query, cache key, queued job, and file upload must be scoped to the correct tenant. The failure is silent: the application works perfectly until a user sees another tenant's data. Global query scopes applied at the model level are the baseline control, but they can be bypassed by certain Eloquent query patterns, which is why we test for tenant leakage explicitly in our integration test suites.

Defending against injection, XSS, and CSRF in practice

These three attack vectors account for the majority of web application vulnerabilities. Laravel provides strong defaults for each, but defaults only work when developers stay within the framework's conventions. Every API integration and third-party data source introduces additional input surfaces that need the same level of validation.

Security headers

We configure security headers at the web server level to provide client-side defence in depth. Every application we deploy scores A+ or higher on the HTTP Observatory.

• Strict-Transport-Security: max-age=31536000; includeSubDomains; preload enforces HTTPS
• Content-Security-Policy restricts script, style, and connection sources
• X-Content-Type-Options: nosniff prevents MIME-type sniffing
• X-Frame-Options: DENY blocks clickjacking
• Referrer-Policy: strict-origin-when-cross-origin limits referrer leakage
• Permissions-Policy disables unused browser features (camera, microphone, geolocation)

Secrets, dependencies, and the software supply chain

Environment variables are Laravel's primary secrets mechanism through .env files. The rules are non-negotiable: .env is in .gitignore, never committed to version control. Production secrets are injected through the hosting environment or a secrets manager (AWS Secrets Manager, HashiCorp Vault), never baked into container images or deployment artefacts.

Dependency security is a software supply chain problem. A Laravel application with 80 Composer packages and 200 npm packages carries a large attack surface composed mostly of code nobody on the team wrote. We manage this through automated scanning in CI, Dependabot or Renovate for update pull requests, lock file integrity verification, weekly security advisory reviews, and version pinning for production deployments. The Log4Shell vulnerability in 2021 demonstrated that a single transitive dependency can compromise an entire fleet.

Deployment pipelines and zero-downtime releases

Security and operations converge at the deployment pipeline. A manual deployment process, where someone SSHes into a server and runs git pull, is both a security risk and an operational liability. Every manual step is an opportunity for inconsistency, and every SSH session is an attack surface.

Our standard deployment pipeline uses GitHub Actions or GitLab CI with four stages.

Zero-downtime deployment means the application serves requests continuously during release. The old version handles requests until the new version is fully ready, then a symlink swap makes the transition atomic. If the new version fails health checks, the symlink reverts. No maintenance windows, no "please try again in five minutes." Database migrations run as part of this pipeline, with careful attention to backwards compatibility so the old application version can still serve requests while the migration executes.

Infrastructure is defined as code (Terraform, Ansible) and version-controlled alongside the application. Server configuration changes go through the same review process as application code. This eliminates configuration drift, where production slowly diverges from what anyone thinks it looks like, and provides a complete audit trail of every infrastructure change. The approach is sometimes called DevSecOps: treating security, development, and operations as a single integrated discipline rather than separate handoffs.

SSH access to production servers is restricted to key-based authentication only, limited to a small set of IP addresses, and logged. For most operational tasks (restarting queues, clearing caches, running migrations), we use the CI pipeline rather than direct server access. The goal is that nobody needs to SSH into production during normal operations.

Monitoring, backups, and disaster recovery

Security does not end at deployment. An application without monitoring is an application where breaches go undetected.

Backups

Backups follow the 3-2-1 rule: three copies, two different storage types, one offsite. Database backups run hourly with 48-hour retention for hourly snapshots, daily for 30 days, weekly for 12 months. File storage (uploads, generated documents) replicates to a separate region.

The critical discipline is testing restores. We run a full database restore to a staging environment monthly. A backup that has never been restored is not a backup; it is a hope.

Disaster recovery

Recovery requires defined objectives. Recovery Time Objective (RTO) is how quickly the system must be back online. Recovery Point Objective (RPO) is how much data loss is acceptable. For most business applications we build, the targets are RTO under four hours and RPO under one hour. Infrastructure-as-code makes recovery reproducible: spin up new infrastructure, restore the latest backup, update DNS. We document the procedure, and we practice it.

Incident response and UK breach notification

Preparation is the difference between a controlled response and a panic. Most incident response content focuses on what to do during a breach. The more important work happens before one occurs.

Before an incident

Every application we maintain has an incident response document stored offline (not only in the application itself). It contains the system inventory, escalation contacts with out-of-hours phone numbers, hosting provider support channels, a communications approval chain, and a decision tree for the first 60 minutes. This document exists so that the person who discovers the incident at 2am does not have to improvise.

The 72-hour clock

Under GDPR Article 33, organisations must notify the ICO within 72 hours of becoming aware of a personal data breach. The clock starts at discovery, not at the time the breach occurred. This means monitoring and alerting directly affect your compliance window: if you detect a breach 48 hours after it happens, you have already consumed two thirds of your notification period before you start investigating.

After an incident

Post-incident review is mandatory, not optional. We document what happened, how it was detected, what the response timeline looked like, what worked, what did not, and what changes will prevent recurrence. The breach log records every action taken and every decision made, which is exactly what the ICO expects to see if they investigate. This feeds back into the monitoring configuration, the deployment pipeline, and the incident response document itself.

The first 10 fixes in an inherited Laravel application

When we take over an existing application, the security assessment follows a consistent triage order. These are the ten items we check first, ranked by the ratio of risk reduction to effort. Most take minutes to verify and hours to fix if they fail.

1. Check APP_DEBUG in production. If it is true, every error exposes environment variables, database credentials, and full stack traces. This is the single highest-risk, lowest-effort fix.
2. Search Git history for .env commits. Run git log --all --diff-filter=A -- .env. If the file was ever committed, every secret in that file should be considered compromised and rotated.
3. Verify HTTPS enforcement. Check for HSTS headers and confirm the application redirects HTTP to HTTPS. Test with the HTTP Observatory.
4. Audit route-only permission checks. Look for controllers that call authorize() or check gates but do not scope database queries to the authenticated user. This is where IDOR vulnerabilities live.
5. Run composer audit and npm audit. Known vulnerabilities in dependencies are the fastest path to exploitation after configuration errors.
6. Check the deployment method. If deployment involves SSH and git pull on a production server, there is no audit trail, no rollback mechanism, and likely shared credentials.
7. Verify backup existence and last test date. Ask for the most recent restore test. If nobody can provide a date, the backups are unverified.
8. Review CORS and CSRF configuration. Check cors.php for overly permissive origins and the CSRF exclusion list for routes that still use session authentication.
9. Check for mass assignment protection. Laravel's $fillable and $guarded properties are the defence against mass assignment attacks. Verify every model defines one or the other explicitly.
10. Review error handling and logging. Confirm that exceptions are captured (Sentry, Bugsnag) and that the application does not return detailed error information to end users in production.

This triage typically takes half a day. It does not replace a full security audit, but it identifies the issues most likely to cause real damage and feeds into the ongoing maintenance plan.

What this looks like in practice

Web application security is not a feature you add before launch. It is an operational discipline that runs from the first line of code through every deployment and into ongoing maintenance.

These patterns belong in every application from day one. They are the habits that prevent 3am phone calls.

• ✓
  Preventive investment over reactive cost The cost of getting security right is a fraction of the cost of getting it wrong. A breached application means regulatory notification, customer trust damage, and weeks of forensic investigation.
• ✓
  GDPR compliance built in GDPR requires reporting breaches within 72 hours. The preventive investment is measured in hours of configuration. The reactive cost is measured in months and reputation.
• ✓
  Tested backups with verified restoration Not "we think we can restore" but "we did restore on this date and it took 47 minutes."
• ✓
  Proactive monitoring with actionable alerts Problems detected before users report them. Alerts that require response, not dismissal.