OWASP has published the 2025 edition of the Top 10 for web applications. If you skim the list and conclude not much moved, look again — this is the biggest reshuffle since 2021, and two of the changes have direct consequences for how an application security programme should be sequenced.
We read the full publication, including the methodology and the new categories. Here is what changed, why, and what a team running web applications should do about it in the next quarter.
The list
| 2025 | Was | |
|---|---|---|
| A01 | Broken Access Control | #1 — held |
| A02 | Security Misconfiguration | #5 → #2 |
| A03 | Software Supply Chain Failures | new, expands Vulnerable and Outdated Components |
| A04 | Cryptographic Failures | #2 → #4 |
| A05 | Injection | #3 → #5 |
| A06 | Insecure Design | #4 → #6 |
| A07 | Authentication Failures | #7 — renamed |
| A08 | Software or Data Integrity Failures | #8 — held |
| A09 | Security Logging and Alerting Failures | #9 — renamed |
| A10 | Mishandling of Exceptional Conditions | new |
Server-Side Request Forgery, which was its own category at #10 in 2021, has been rolled into Broken Access Control.
The methodology matters for how much weight to give this. OWASP ranked twelve categories on contributed data — roughly 175,000 CVE-to-CWE records from the National Vulnerability Database — and allowed two to be promoted by community survey. The ten categories cover 248 CWEs, averaging 25 each. They state they prioritised root causes over symptoms, which explains most of the movement below.
The four changes that should alter your plan
1. Security Misconfiguration is now the second most important thing on the list
A jump from #5 to #2 is the largest movement in the list, and it is the one most likely to be misread as noise.
It is not noise. Misconfiguration is the category that scales worst with your estate. One misconfigured application is a finding; a misconfigured platform default inherited by two hundred services is a systemic condition, and it does not appear in a code review because there is no code to review.
What to do: stop treating configuration as an artefact of deployment and start treating it as code you review. Concretely — enumerate where your defaults come from (base images, Helm charts, Terraform modules, framework scaffolding), pick the ten settings that would hurt most if wrong, and assert them centrally rather than documenting them. A setting that is documented is a setting that drifts.
If you already run cloud posture management, note that this category is broader than the cloud control plane. It includes the application framework's own defaults, which most posture tools never see.
2. Supply chain is now a first-class category, not a dependency-patching problem
This is the change with the widest blast radius. The 2021 edition had Vulnerable and Outdated Components at #6 — a category most teams operationalised as "run SCA, patch the criticals". A03:2025 explicitly widens the scope to "a broader scope of compromises occurring within or across the entire ecosystem of software dependencies."
That wording is deliberate. It covers the build system, the package registry, the CI credentials, the maintainer account, and the plugin your pipeline pulls at build time — not just the version number in your lockfile.
What to do, in order:
- Inventory what your build can reach. Most teams can name their dependencies and cannot name what their CI has credentials to. That asymmetry is the whole problem.
- Pin and verify, do not just scan. Lockfiles with hashes, pinned action and image digests rather than moving tags. A scanner tells you about known-bad versions; pinning tells you that you got the artefact you asked for.
- Treat the build system as production. Ephemeral runners, least-privilege tokens scoped per job, no long-lived credentials sitting in CI. The build system holds credentials to everything and is almost never in scope for the controls that protect everything.
- Then do the dependency patching you were already doing.
Most organisations have step 4 and none of steps 1 to 3. The reordering is the point.
3. SSRF disappearing is a reclassification, not a downgrade
SSRF has not become less exploitable. OWASP folded it into Broken Access Control because — consistent with their root-cause framing — the underlying failure is that the application makes a request on behalf of a user without adequately deciding whether it should.
What to do: nothing, if your controls were already sound. But check one thing — if SSRF appeared as a discrete line item in a compliance mapping, a test plan, or a pen-test scope, it now has no home in the 2025 taxonomy and will quietly fall off the next revision of that document. Rename the control before it becomes a gap that nobody owns.
This is the specific way taxonomy changes cause real damage: not through the risk changing, but through a scope document losing a row.
4. There is a genuinely new category at #10, and it is the one nobody is ready for
Mishandling of Exceptional Conditions covers 24 CWEs and has no predecessor in the list. OWASP describes it as software that "fails to prevent, detect, and respond to unusual and unpredictable situations, which leads to crashes, unexpected behavior, and sometimes vulnerabilities."
Three failure modes: the application does not prevent the unusual situation, does not notice it, or responds to it badly. The CWEs include error messages that leak system information (CWE-209), missing-parameter handling (CWE-234), null pointer dereference (CWE-476), and failing open (CWE-636).
The attack scenarios OWASP gives are worth reading closely, because they do not look like security bugs:
- A file-upload handler that fails to release resources on the exception path, until the service exhausts itself.
- A database error surfacing enough system detail for an attacker to shape a targeted injection.
- A network interruption mid-transaction with no rollback — enabling duplicate transfers or a drained account.
Note what these have in common. Every one of them would be filed as a reliability defect, not a vulnerability. That is exactly why the category exists, and why it is the hardest one to add to an existing programme: your scanners will not find these, and your triage process has spent years teaching engineers that stability bugs go in a different queue.
What to do: OWASP's own guidance is unusually concrete. Catch errors where they occur rather than at the top of the stack. Fail closed — roll the transaction back rather than partially recovering. Apply rate limits, resource quotas and throttling. Centralise error handling and logging, with a global exception handler as a backstop, not as the primary mechanism.
Practically, the highest-value first move is to go through your error paths and ask a single question of each: if this fires ten thousand times in a minute, what runs out, and what is left half-done?
What this means for your next quarter
If your application security programme was scoped against the 2021 list — and most were, because that is what compliance mappings and pen-test statements of work reference — then three of your priorities have moved and one workstream does not exist yet.
A sensible sequence:
- Re-rank your existing backlog against the new order. Nothing new to build; you are just reweighting. Misconfiguration work that was queued behind injection work probably should not be any more.
- Widen supply chain from SCA to the build system. This is the largest genuinely new body of work and the one with the worst current coverage.
- Fix the taxonomy in your documents — scopes, mappings, reporting templates — before SSRF silently falls out of all of them.
- Open exceptional conditions as a small, deliberate workstream. Start with error paths in anything handling money, files, or external calls. Do not try to boil it.
One caution on all of this. The Top 10 is an awareness document built from CVE data, and it describes what is commonly found across the industry — not what is most dangerous in your estate. A retail platform and a public-sector case management system do not share a threat model just because they share a framework. Use the list to check that nothing significant is unowned, not as a substitute for knowing where your own sensitive data actually sits.
The teams that get value from this edition will be the ones that treat it as a prompt to re-rank, not a new checklist to start from the top.
Want help putting this into practice?
We work alongside your team to design, build, and operate the controls described above.