Five Numbers From 10,000 Laravel Applications

We published the State of Laravel Security 2026 report earlier this year, based on external scans of more than 10,000 Laravel applications. Everything in it was measured from outside, which is the same view an attacker gets, and a very different view from the one a code review gives you.

Five findings have stuck with me, mostly because they complicate the advice we and everyone else routinely give.

34% carry a critical finding

A third of applications scanned had at least one issue in the critical band: an exposed .env file, debug mode enabled in production, or an exposed Telescope instance.

The thing to sit with is that none of these are hard problems. There is no cryptography here, no architectural rework, no dependency untangling. Each one is a configuration value or a route that should not be reachable. The median time to fix any of them is minutes.

So the gap is not capability. Every one of those teams could have fixed every one of those findings the same afternoon. The gap is that nobody told them, because nothing checks from outside on an ongoing basis, and the inside view never shows you what your production deployment is actually serving.

18% run debug mode in production

This is the one I would fix first in any application, and it is the finding where the distance between "misconfiguration" and "total compromise" is shortest.

A Laravel debug page does not just say something went wrong. It renders a stack trace with environment context, and that routinely includes APP_KEY, database credentials, mail credentials, and whatever third-party tokens you have configured. An attacker does not need to find an exploit. They need to find an error, and errors are easy to cause.

APP_KEY in particular is not merely a secret. Laravel uses it for signed and encrypted payloads, and with it in hand an attacker can forge things your application will trust. We went through that chain in your Laravel APP_KEY is on GitHub, that means remote code execution, and the same conclusion applies whether the key leaked through a repository or through a stack trace.

Eighteen percent. Roughly one in five.

72% are missing security headers, and that is the least of it

The most common finding in the dataset is also the least severe, and I think this is where a lot of security advice goes wrong.

Header adoption from the scans: X-Content-Type-Options at 68%, X-Frame-Options at 61%, HSTS at 54%, Referrer-Policy at 41%, Content Security Policy at 22%, Permissions-Policy at 14%.

Headers are worth fixing. They are cheap, they are quick, and CSP in particular does real work. But a missing Referrer-Policy is not in the same category as a readable .env file, and the two get flattened together by scoring systems that count findings rather than weighing them.

If your scan report lists eleven header issues and one exposed environment file, the correct order of work is the environment file, then possibly nothing else that week. The report's own scoring reflects that weighting, and it is worth checking that whatever tool you use does the same, because a long list of low-severity findings is very good at consuming the attention that one critical finding deserved. That is most of what we mean by reading a scan report properly.

Version distribution says the real problem is elsewhere

Of the applications scanned: Laravel 11 at 38%, Laravel 10 at 31%, Laravel 9 at 16%, and Laravel 8 or older at 15%.

Nearly a third are on a branch that has left active support, and 15% are on Laravel 8 or older, which has been out of support for a long time.

This is the finding with the worst effort-to-severity ratio in the whole report. Turning off debug mode is a one-line change. Moving a Laravel 8 application to a supported branch is weeks of work, possibly months, and it competes against product deadlines every sprint. It never wins that argument on security grounds alone, which is why so many applications sit there.

It also compounds. Every advisory published against the supported branches, including the two Laravel framework advisories from June this year, simply remains permanently true of these applications. They do not accumulate a to-do list, they accumulate an unpatched surface.

If you are on an unsupported branch, the practical move is not to argue for a security-motivated upgrade. It is to attach the upgrade to work that has product value, and to compensate meanwhile: strict headers, tight external surface, and monitoring that tells you when something changes. The full argument for that middle path is in continuous security monitoring versus annual pentesting.

89% improved after monitoring, with a caveat

The most encouraging number, and the one I want to be careful about.

Eighty-nine percent of applications improved their score once continuous monitoring was in place. That sounds like a strong claim for monitoring, and I run a monitoring product, so treat my enthusiasm accordingly.

The honest caveat is selection. Teams that adopt monitoring are teams that already care, which means they were more likely to improve regardless. This is not a controlled experiment and I would not present it as one.

What I think it does support is narrower and still useful: for the class of problems in this report, the binding constraint is visibility rather than capability. These are not findings that require expertise to fix. They are findings that require somebody to know they exist. Once a team can see them, most get fixed, which is roughly what you would expect when the fixes are this cheap.

The average score across the dataset was 62 out of 100. That is not a target to aim at. It is a description of what normal looks like, and normal includes one in five applications leaking their environment through a stack trace.

What to do with this

If you take one thing: go and check, from outside, whether your production application currently exposes .env, renders debug pages, or serves Telescope. Those three findings account for the critical band in this dataset and they are all verifiable in a couple of minutes.

Run a free scan and it will tell you in about a minute. The full report has the complete breakdown including the header adoption figures and the methodology behind the scoring.