The OWASP Top 10 Just Changed. Here Is What It Means for Laravel Teams.

The OWASP Foundation published the OWASP Top 10 2025, the first update since 2021. Based on analysis of 175,000+ vulnerabilities across 340,000 repositories and 13,000 organizations, the new list reflects how application security risks have shifted over the past four years.

Two new categories enter the list. Two existing categories swapped positions significantly. And the changes map directly onto risks that Laravel teams deal with every day.

The full OWASP Top 10 2025

Server-Side Request Forgery (SSRF), previously #10, was merged into Broken Access Control — OWASP now treats it as fundamentally an access control problem.

What changed and why it matters for Laravel

Security Misconfiguration rises to #2

This is the most significant move for Laravel teams. Security misconfiguration jumped from #5 to #2, reflecting the reality that modern applications fail more often from how they are configured than from bugs in their code.

In Laravel, this includes:

• APP_DEBUG=true in production — exposes stack traces, database credentials, environment variables, and internal file paths
• Exposed Telescope — gives attackers a real-time view of every request, query, job, and log entry
• Exposed Horizon — reveals your queue infrastructure and job data
• Exposed Ignition — Laravel's error page includes environment details and file contents
• Missing security headers — no CSP, HSTS, X-Frame-Options, or X-Content-Type-Options
• Accessible .env file — serves your entire secrets file to anyone who requests it
• Default credentials — database, cache, or queue connections using default passwords

The key insight is that these are not code bugs. Your application code can be flawless, and a single environment variable or web server misconfiguration can expose everything. This is why misconfiguration now outranks injection.

Supply Chain Failures enters at #3

The previous OWASP list included "Vulnerable and Outdated Components" at #6, which covered known CVEs in your dependencies. The new "Software Supply Chain Failures" is broader, covering:

• Compromised dependencies — malicious code injected into legitimate packages
• Malicious packages — fake packages with typosquatted or deceptive names
• Tampered builds — build pipelines that inject code during compilation
• Insecure update mechanisms — update channels that can be hijacked

This is not theoretical. In March 2026, three malicious packages on Packagist disguised as Laravel utilities deployed a RAT that gave attackers full shell access. The packages had legitimate-sounding names and the author had published clean packages first to build credibility.

For Laravel teams, supply chain security means:

# Run on every CI build
composer audit

# Check for known vulnerabilities in npm dependencies too
npm audit

But composer audit only catches known CVEs. It does not detect malicious packages that have not been flagged yet. You also need to:

• Review new dependencies before installing (check the author, download count, repository)
• Pin exact versions for critical packages
• Monitor your application's behavior in production for unexpected changes

Injection drops to #5

Injection falling from #3 to #5 is good news for Laravel developers — it reflects that frameworks like Laravel have made the default path secure:

• Eloquent ORM uses parameterized queries, preventing SQL injection by default
• Blade templates escape output with {{ }}, preventing XSS by default
• CSRF middleware is enabled by default on all web routes

But "by default" is doing heavy lifting in that sentence. Injection remains a risk when developers bypass the defaults:

// SQL injection — using raw queries without bindings
DB::select("SELECT * FROM users WHERE email = '$email'");

// XSS — using unescaped Blade output
{!! $userInput !!}

// Command injection — passing user input to shell commands
exec("convert " . $request->input('filename'));

The lesson is not that injection is solved. It is that the framework protects you until you reach for the escape hatch.

Mishandling of Exceptional Conditions enters at #10

The new #10 category covers what happens when your application encounters an error:

• Verbose error messages that leak internal details (database schema, file paths, environment variables)
• Unhandled exceptions that crash the application or leave it in an inconsistent state
• Inconsistent error responses that reveal whether a resource exists (user enumeration)

In Laravel, the most common manifestation is APP_DEBUG=true in production. When debug mode is enabled, any unhandled exception displays:

• Full stack trace with file paths
• Environment variables (including APP_KEY, database credentials, API keys)
• Database query details
• Request data

This is now an OWASP Top 10 category, not just a best practice recommendation.

// config/app.php — never hardcode this
'debug' => env('APP_DEBUG', false), // Default must be false

// Handler.php — customize production error responses
protected function shouldntReport(Throwable $e)
{
    // Log the error internally but show a generic message to users
}

What to do about it

1. Audit your configuration (Misconfiguration, #2)

The most impactful thing you can do is verify that your production environment is configured correctly:

# Check debug mode
php artisan tinker --execute="dump(config('app.debug'))"
# Must return false

# Check .env accessibility
curl -s -o /dev/null -w "%{http_code}" https://yourdomain.com/.env
# Must return 403 or 404, not 200

# Check Telescope accessibility
curl -s -o /dev/null -w "%{http_code}" https://yourdomain.com/telescope
# Must return 403 or 404

Or use external monitoring that checks all of these automatically, on every scan, after every deployment.

2. Secure your supply chain (#3)

# Add to your CI/CD pipeline
composer audit --format=json
npm audit --audit-level=high

# Review what a package autoloads before installing
composer show --all vendor/package-name

Establish a team policy: no new Composer package gets installed without checking the author's profile, the package's download count, and the repository's commit history.

3. Harden your error handling (#10)

// Ensure APP_DEBUG is false in production
// .env.production
APP_DEBUG=false

// Custom error pages
// resources/views/errors/500.blade.php
// resources/views/errors/404.blade.php

// Report errors to a monitoring service, not to users
// app/Exceptions/Handler.php

4. Do not bypass framework defaults (#5)

Keep using Eloquent instead of raw queries. Keep using {{ }} instead of {!! !!}. Keep CSRF middleware enabled. Every time you reach for a raw or unescaped alternative, you are opting out of Laravel's built-in injection protection.

5. Monitor continuously

The OWASP Top 10 changes reflect a shift from "secure your code" to "secure your entire deployment." Configuration drift, supply chain compromises, and error handling failures all happen at runtime, not at code review time. External monitoring catches these issues in production, where they actually matter.

Key takeaways

1. Security misconfiguration (#2) is the biggest risk for Laravel teams — debug mode, exposed tools, and missing headers are more common than code-level vulnerabilities
2. Supply chain attacks (#3) are real and targeting Laravel specifically — malicious Packagist packages were discovered this month
3. Injection (#5) is mitigated by Laravel's defaults — but only when you use them
4. Error handling (#10) is now a Top 10 category — APP_DEBUG=true in production is officially an OWASP-listed risk
5. The shift is from code to configuration — your biggest risks are not in your application logic but in how your application is deployed and configured