How to Security Audit a Laravel Application: A Practical Guide

A security audit does not need to be a six-figure engagement. For most Laravel applications, a structured self-audit catches the majority of exploitable issues. This guide walks through the process step by step.

Phase 1: Dependency Scanning (15 minutes)

Start with what is already known to be vulnerable.

Run composer audit

composer audit

This checks every package in your composer.lock against the PHP Security Advisories Database. Any result here is a known vulnerability with a public exploit path.

Prioritise by severity:

• Critical/High: Update immediately. These have known exploits.
• Medium: Update this sprint. These are exploitable under specific conditions.
• Low: Update when convenient. These are theoretical or require unusual configurations.

If you cannot update a package (breaking changes, abandoned package), document the risk and check whether the specific vulnerability applies to your usage.

Check for abandoned packages

composer outdated --direct

Packages that have not been updated in over a year may have unpatched vulnerabilities that are not in the advisories database yet. Consider replacing them.

For a deeper dive on managing PHP dependency vulnerabilities, see our composer audit guide.

Phase 2: Configuration Review (30 minutes)

Configuration mistakes are the most common cause of Laravel security incidents. They are also the easiest to find and fix.

Environment settings

Check your production .env (or environment variables):

CORS configuration

Open config/cors.php and check:

// DANGEROUS: any site can call your API as the user
'allowed_origins' => ['*'],
'supports_credentials' => true,

// SAFE: explicit origin list
'allowed_origins' => ['https://yourdomain.com', 'https://app.yourdomain.com'],
'supports_credentials' => true,

Wildcard origins with credentials enabled is the single most exploitable CORS misconfiguration.

CSRF exceptions

Open app/Http/Middleware/VerifyCsrfToken.php and check the $except array. Every URL listed here is unprotected from CSRF. Webhook endpoints from Stripe or GitHub are fine. Application routes that change state are not.

Telescope, Horizon, and debug tools

If installed in production, these must be gated behind authentication:

Gate::define('viewTelescope', fn ($user) => $user->is_admin);

An ungated Telescope instance exposes every database query, every request payload, and every job in your queue.

Phase 3: External Scanning (15 minutes)

Check what your application looks like from the outside.

Automated external scan

Run a free StackShield scan to check for:

• Exposed .env files
• Debug mode detection
• Missing security headers
• SSL/TLS configuration issues
• Directory listing
• Publicly accessible Telescope/Ignition/Horizon
• Subdomain takeover risks
• Session cookie security flags

This catches the configuration issues from Phase 2 that have actually made it to production, plus infrastructure-level issues you cannot see from inside the application.

Manual checks

A few things to verify manually:

# Check if .env is accessible
curl -sI https://yourdomain.com/.env | head -1

# Check security headers
curl -sI https://yourdomain.com | grep -iE "(strict-transport|x-frame|x-content-type|content-security|referrer-policy)"

# Check for directory listing
curl -s https://yourdomain.com/storage/ | head -5

Phase 4: Code Review (2-8 hours)

This is the most time-intensive phase but catches vulnerabilities that automated tools miss.

XSS vectors

Search your Blade templates for unescaped output:

grep -r '{!!' resources/views/ | grep -v '.svn'

Every {!! !!} is a potential XSS vulnerability. For each one, verify the data source is trusted or properly sanitized. See our XSS prevention guide.

SQL injection

Search for raw queries:

grep -rn 'DB::raw\|->whereRaw\|->selectRaw\|->orderByRaw\|->havingRaw' app/

Each raw query that includes user input without bindings is a SQL injection vector. Use parameterized queries:

// Vulnerable
DB::select("SELECT * FROM users WHERE email = '$email'");

// Safe
DB::select('SELECT * FROM users WHERE email = ?', [$email]);

Mass assignment

Check your models for unprotected mass assignment:

grep -rn 'protected \$guarded = \[\]' app/Models/

$guarded = [] means every column is mass-assignable. Use $fillable to explicitly list allowed fields instead.

Authorization checks

For every controller action that accesses or modifies data, verify there is an authorization check. Look for:

• Missing $this->authorize() calls
• Missing Policy checks
• Direct model access without ownership verification (e.g., User::find($id) without checking the requesting user owns that record)

File upload handling

Search for file upload handling and verify:

• MIME type validation (not just extension)
• File size limits
• Storage location is not publicly accessible
• Filenames are randomized, not user-controlled

Phase 5: Prioritise and Fix

After the audit, you will have a list of findings. Prioritise them:

Fix immediately (this deployment):

• Exposed .env file
• Debug mode enabled
• Known dependency vulnerabilities (critical/high)
• SQL injection
• Ungated debug tools

Fix this week:

• Missing security headers
• Insecure session configuration
• CORS misconfiguration
• XSS in user-facing pages

Fix this sprint:

• Mass assignment issues
• Missing rate limiting
• Authorization gaps
• Medium-severity dependency updates

Track for next quarter:

• Content Security Policy implementation
• Comprehensive authorization review
• Penetration test

Automate What You Can

Manual audits catch problems. Automated monitoring prevents them from recurring.

• Dependencies: Run composer audit in CI/CD. Fail the build on critical advisories.
• External surface: Use StackShield to scan continuously after every deployment.
• Static analysis: Add PHPStan or Psalm to your CI pipeline with security-focused rules.

A quarterly manual audit combined with continuous automated monitoring is the most practical approach for most Laravel teams.

Start with a free StackShield scan to baseline your current security posture.