The OWASP Top 10 was updated to a 2025 edition, and 2021 is now listed as a previous version. If your security report still cites 2021, it is quoting a retired standard to whoever reads it — and the renumbering alone changes most of the answers.
We found this in our own product. Our compliance table mapped every finding to a 2021 category, which is what almost every scanner did until recently. Checking it against OWASP's own pages turned up more than a version bump.
The 2025 list
A01 Broken Access Control
A02 Security Misconfiguration
A03 Software Supply Chain Failures
A04 Cryptographic Failures
A05 Injection
A06 Insecure Design
A07 Authentication Failures
A08 Software or Data Integrity Failures
A09 Security Logging & Alerting Failures
A10 Mishandling of Exceptional ConditionsBroken Access Control keeps the top spot. Everything under it moved.
The renumbering is not cosmetic
Three of the categories people quote most often changed number:
- Injection moved from A03 to A05
- Cryptographic Failures moved from A02 to A04
- Security Misconfiguration moved up from A05 to A02
That last one is worth sitting with. Misconfiguration rose three places, which is a statement about where breaches are actually coming from: not exotic injection chains, but settings left at defaults.
SSRF stopped being its own category
A10:2021 was Server-Side Request Forgery. In 2025 it does not exist as a category — CWE-918 was folded into A01: Broken Access Control, alongside 39 other CWEs.
This is the change most likely to break a mapping quietly. A scanner that hardcoded "SSRF → A10" will now point at A10:2025 Mishandling of Exceptional Conditions, which is an entirely different thing about error handling. The mapping still produces a plausible-looking answer; it is just wrong.
Where the reasoning lands
Reading it as access control rather than as a request-forgery problem of its own makes sense: the damage from SSRF is reaching something you were not authorised to reach. It sits with CWE-200 and CWE-201 — exposure of information to an unauthorised actor — and with CSRF.
Vulnerable components became supply chain failures
A06:2021 was "Vulnerable and Outdated Components": you are using a library with a known advisory. A03:2025 is Software Supply Chain Failures, and the scope widened to compromises across the whole dependency, build and distribution ecosystem.
The category also moved from sixth to third. An outdated package with a CVE is one case of it; a compromised build step or a malicious publish to a registry is another, and until now neither had an obvious home in the list.
Two renames and one new entry
- A07 — "Identification and Authentication Failures" is now just Authentication Failures
- A09 — "Logging and Monitoring" became Logging & Alerting. Monitoring you never look at is not a control; alerting is the part that does something.
- A10 — Mishandling of Exceptional Conditions is new: 24 CWEs about error handling, unchecked returns, and what happens when something goes wrong in a way nobody planned for.
A10 is the interesting addition. It covers CWE-209 (information exposure through an error message), CWE-476 (null dereference), CWE-252 (unchecked return value) and CWE-703 (improper check for unusual conditions) among others — a family of bugs that were previously scattered or absent.
What this means if you map findings to categories
Our own mapping was doing something worse than being out of date. It read the finding's prose first and the CWE second, so a complaint about a regular expression that "includes nested quantifiers" was filed as file inclusion, because the keyword list carried the bare word include.
The fix was to invert it. OWASP publishes the CWE list for every category. All ten of them, 249 CWEs, none of them appearing in two categories. So the CWE decides, and prose is consulted only when a finding carries no CWE at all.
Checking your own tooling
Three things worth looking at in whatever produces your compliance reports:
- Does it cite 2025 or 2021? Check what number it puts next to Injection — A05 or A03.
- Where does it put SSRF? If it still says A10, the mapping is hardcoded and now points at a category about error handling.
- Does every finding get a category? If nothing is ever unmapped, something is being assigned by default, and defaults are how a report states things it does not know.
None of this makes a scanner better at finding vulnerabilities. It makes the report honest about what it found — which is the part an auditor reads.
The previous post is about the other half of the same problem: what happens when the findings themselves are the tool's own rules.