The OWASP Top 10 was renumbered in 2025. Here is what moved
Somebody on your team cites A03 in a ticket. Somebody else reads it and thinks “injection”, because that is what A03 meant for four years. It now means software supply chain failures. The list was renumbered, two categories are new, and a large share of the security content on the internet — including, probably, your own control mapping — still describes the previous edition.
The short version
The OWASP Top 10:2025 reorders the categories, renames two of them, folds Server-Side Request Forgery into Broken Access Control, and introduces two categories that did not previously exist as categories. The project describes the change as two new categories and one consolidation.
Nothing about that makes older work worthless. It does mean that a bare reference to “A03” in a report, a policy or a contract is now ambiguous, and that the edition has to be named wherever the number is used.
The 2025 list, in order
- A01:2025 — Broken Access Control. Holds first place. Server-Side Request Forgery, which stood alone at A10 in 2021, has been rolled into it.
- A02:2025 — Security Misconfiguration. Up from fifth.
- A03:2025 — Software Supply Chain Failures. An expansion of the former Vulnerable and Outdated Components, widened to the whole ecosystem of dependencies, build systems and distribution infrastructure.
- A04:2025 — Cryptographic Failures. Down from second.
- A05:2025 — Injection. Down from third.
- A06:2025 — Insecure Design. Down from fourth.
- A07:2025 — Authentication Failures. Holds seventh place, renamed from Identification and Authentication Failures.
- A08:2025 — Software or Data Integrity Failures. Holds eighth place.
- A09:2025 — Security Logging and Alerting Failures. Holds ninth place, renamed from Security Logging and Monitoring Failures.
- A10:2025 — Mishandling of Exceptional Conditions. New for 2025.
What moved, side by side
| 2021 | 2025 | What happened |
|---|---|---|
| A01 Broken Access Control | A01 Broken Access Control | Unchanged in rank; absorbed SSRF |
| A02 Cryptographic Failures | A04 Cryptographic Failures | Down two places |
| A03 Injection | A05 Injection | Down two places |
| A04 Insecure Design | A06 Insecure Design | Down two places |
| A05 Security Misconfiguration | A02 Security Misconfiguration | Up three places |
| A06 Vulnerable and Outdated Components | A03 Software Supply Chain Failures | Expanded and renamed |
| A07 Identification and Authentication Failures | A07 Authentication Failures | Renamed |
| A08 Software and Data Integrity Failures | A08 Software or Data Integrity Failures | Narrowed in emphasis |
| A09 Security Logging and Monitoring Failures | A09 Security Logging and Alerting Failures | Renamed |
| A10 Server-Side Request Forgery | Folded into A01 | No longer a category |
| — | A10 Mishandling of Exceptional Conditions | New category |
The 2021 edition remains published at owasp.org/Top10/2021, which is the reference to use when you need to read a historical report accurately.
What is genuinely new: supply chain as its own category
The former Vulnerable and Outdated Components was, in practice, a dependency patching category. Teams answered it with a scanner over the dependency manifest and an upgrade backlog. Software Supply Chain Failures is broader by design: the project describes it as covering compromises occurring within or across the entire ecosystem of software dependencies, build systems and distribution infrastructure.
That wording reaches things a manifest scanner never sees. Who can push to the build system. Whether build steps execute code fetched at build time. Whether the artifact that ships is the artifact that was built and reviewed. Whether a published package could be replaced upstream without anything in your pipeline noticing. Whether a developer machine with a compromised extension can reach a signing key.
The honest consequence for most organizations is that they have no coverage here at all, because the previous category let them believe a dependency report was the answer. Closing it is build and release engineering work more than it is application work; it belongs with the practices in secure development.
Why did logging get renamed?
Security Logging and Monitoring Failures became Security Logging and Alerting Failures. The project is explicit about the reason: great logging with no alerting is of minimal value in identifying security incidents.
That changes what a reviewer looks for. Under the old wording, a team could satisfy the category by demonstrating that the events existed somewhere and were retained. Under the new wording the question is what happens next — which events raise an alert, who receives it, how quickly, and whether anybody acted on the last one. A retention policy with nobody watching it is now the failure the category is named after.
Mishandling of exceptional conditions: the one nobody has tested
The new A10 covers improper error handling, logical errors, failing open, and related scenarios arising from abnormal conditions a system may encounter. It is the category most likely to be absent from your last test, because it does not look like a vulnerability class — it looks like reliability.
The questions it prompts are ones an engineer can answer immediately, and rarely has been asked. When the authorization service times out, does the request proceed or stop? When the rate limiter’s backing store is unreachable, does the limit still apply? When signature verification throws rather than returning false, is the exception caught somewhere that treats it as success? When a partial failure leaves a transaction half-applied, what state is the record in, and who can act on it before it is repaired?
These are design questions as much as code questions, which is why they are better surfaced in a threat model than found late in a test window.
What this changes in a test scope
Three things, concretely.
- Name the edition in the scope document. “Tested against the OWASP Top 10” without a year is no longer a specification. Write “Top 10:2025”.
- Decide explicitly whether supply chain is in scope. It usually needs access a black-box application test does not have — repository, pipeline configuration, artifact provenance — and it is often a separate review rather than part of the application window.
- Ask for exceptional-condition cases by name. Fault injection against dependencies, timeouts on authorization paths and failure modes of security middleware are cheap to request in advance and expensive to add halfway through.
Renumbering alone is not a reason to retest. Two of the changes are, because they widen what is in scope: software supply chain failures and the mishandling of exceptional conditions are rarely covered by a test scoped before 2025. The rest of the changes are renumbering, and renumbering is a documentation task. There is more on getting the scope itself right in how to scope a penetration test, and on what comes back in what a report should contain.
What this changes in a control mapping
Most frameworks name the OWASP Top 10 without pinning an edition, which means the edition is a decision you make and record rather than one the framework makes for you. Where a contract, a policy or a customer questionnaire cites the list, the practical move is to state the edition once, in the place the mapping lives, and to keep the previous edition’s numbers alongside for as long as historical reports are still in circulation.
Two mappings need rewriting rather than renumbering. Anything that pointed at the old components category now has a wider target and will show a gap. Anything that treated SSRF as its own control now belongs under access control, where it sits beside the rest of the server-side request problem rather than off on its own.
Is your existing report against the old list?
Four tells, in order of reliability. The report names an edition on the methodology page — read it. The findings reference A10 as Server-Side Request Forgery, which only the 2021 list does. The findings reference “Vulnerable and Outdated Components”, which is the 2021 name. Or the logging category is called “Monitoring”, which is also 2021.
If the report predates the 2025 list, it is still valid evidence of what was tested and found. It is simply evidence against a different index, and a reader in 2027 will need to be told which one. Say so in a covering note rather than renumbering somebody else’s report.
Not to be confused with the list for LLM applications
The OWASP Top 10 for LLM Applications 2025 is a separate list from a separate project, numbered LLM01 to LLM10, and it does not replace or extend the web application list. It is published by the OWASP Gen AI Security Project at genai.owasp.org and names prompt injection, sensitive information disclosure, supply chain, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation, and unbounded consumption.
Both lists have a supply chain category and both were published for 2025, which is how they get conflated in questionnaires. A system with a model in it needs both: the web application list for the application around the model, and the LLM list for the model, its retrieval and its tools. We take the second one apart in the OWASP LLM Top 10 for buyers.
How the work is bounded
The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.
Testing and adversary simulation are carried out only with signed authorization, to a scope agreed in writing.
SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.
Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.
Questions we are asked
Is the 2021 OWASP Top 10 wrong now?
The 2021 list is not wrong; it is superseded. Findings written against it remain true findings, but the category numbers no longer line up with the current list, so a mapping written in 2022 will mislabel work done today.
Does our compliance framework require the 2025 list?
Most frameworks name the OWASP Top 10 without pinning an edition, which means the edition is a decision you make and record rather than one the framework makes for you.
Should we re-test against the new list?
Renumbering alone is not a reason to retest. Two of the changes are, because they widen what is in scope: software supply chain failures and the mishandling of exceptional conditions are rarely covered by a test scoped before 2025.
Is this the same as the OWASP Top 10 for LLM Applications?
The OWASP Top 10 for LLM Applications 2025 is a separate list from a separate project, numbered LLM01 to LLM10, and it does not replace or extend the web application list.
Testing against the current list
Send the scope of your last test and we will say which categories it reached and which two it almost certainly did not. Our testing work is described under penetration testing, and the rest of our writing is indexed at writing.