OWASP Top 10 2025 vs 2021: What Changes in Your Reports

The OWASP Top 10 2025 is the current edition, and it changes which category a lot of routine web findings map to. As of October 2026 it is the final release: it first appeared as a release candidate on 6 November 2025 and was finalised at the end of December 2025, so a report written today should reference 2025, not 2021. This page sets the two editions side by side, explains what actually moved and why, and covers the part the developer explainers skip: re-mapping a findings library and your report templates without invalidating everything you delivered under 2021.

The verified figures and category names here come from the OWASP Top 10 project's own pages and repository. The edition is data-informed for eight of its ten categories and set by a community survey for the other two, drawn from data on over 2.8 million applications, with 248 of the CWE identifiers distributed across the ten categories.

2025 against 2021, in one table

The 2025 order is 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 and Alerting Failures, A10 Mishandling of Exceptional Conditions.

What moved and why

• Broken Access Control stays at number one. It had the highest number of occurrences in the data, and SSRF has been rolled into it, so the top category is now broader than before.
• Security Misconfiguration rose from fifth to second. More of an application's behaviour is driven by configuration than it used to be, and misconfigurations were more prevalent in this cycle's data.
• Software Supply Chain Failures rose to third as an expansion of 2021's Vulnerable and Outdated Components. It was the top concern in the community survey, and it covers the whole ecosystem of dependencies, build systems and distribution, not only components with known flaws.
• Cryptographic Failures, Injection and Insecure Design each fell two places, to fourth, fifth and sixth. They did not get less important; the categories above them climbed. Insecure Design falling is read by the project as a sign that threat modelling and secure design have improved since 2021.
• The bottom three are mostly renames. Identification and Authentication Failures became Authentication Failures, and Security Logging and Monitoring Failures became Security Logging and Alerting Failures, to stress that logging without alerting catches nothing.

The two new categories in practice

A03 Software Supply Chain Failures is where a finding about an out-of-date dependency now lands, but the category is wider than that. It takes in a compromised build pipeline, a package pulled from an untrusted source, and a dependency that cannot be updated. It has the fewest occurrences in the data, which the project attributes to how hard this area is to test, and the highest average exploit and impact scores from the CVEs that do map to it. In a report, a routine "unsupported component" finding reads better as A03:2025 with a sentence on where in the supply chain the weakness sits.

A10 Mishandling of Exceptional Conditions is genuinely new. It covers improper error handling, logical errors and systems that fail open rather than closed, including error messages that leak sensitive detail. Several of these weaknesses used to be filed under generic "poor code quality" or, in the case of verbose error messages, under 2021's Insecure Design. If you raise a finding about a system that reveals internal detail when it errors, or that grants access when a check fails, A10:2025 is now its home.

Where SSRF now sits

Server-Side Request Forgery was its own category, A10, in 2021. In 2025 it is folded into A01 Broken Access Control, where its CWE identifier sits alongside the other access-control weaknesses. For a report this means an SSRF finding should cite A01:2025, not a standalone SSRF category. The weakness has not changed and its severity is unaffected; only its label in the Top 10 has. It is worth a line in the report so a reader who knows the 2021 list is not confused by the move.

Re-mapping a findings library and templates

Most of the work of adopting 2025 is clerical, and it is worth doing in one pass rather than discovering a stale reference mid-engagement. The common moves below are the ones that touch routine findings.

• Update the reference, keep the wording. The description and remediation of a reused finding rarely change; only the category tag does. Change the tag, leave the prose.
• Do it in the library, not per report. If the category reference lives in your reusable findings, one edit fixes every future report. The reasoning for keeping reused findings in a single library applies directly here.
• Carry it into the template as a field. A category reference that the template fills from a field, rather than one typed into the body, means the mapping is applied the same way every time. Setting that up is covered in configuring report templates.

Explaining it to clients

A client who tracks the Top 10 will notice that a finding they saw under one category last year is under another this year, and the question lands on you. Three sentences settle it.

• The weakness and its severity have not changed; the Top 10 reorganised its categories in the 2025 edition.
• Name both references for a transition period, for example "A05:2025 Injection (A03:2021)", so a reader using either list can follow.
• If the client's own standard or contract still cites 2021, agree which edition the report maps to before you write it, and say so in the methodology.

The Top 10 is an awareness document, not a testing methodology. A web test is still driven by a full checklist such as the OWASP Testing Guide; the Top 10 is how you group the findings for a reader, not what you test.

Versioning category references in reports

The lesson of every Top 10 revision is that an undated reference ages badly. "OWASP A3" meant Injection in 2017, Cross-Site Scripting before that, and Sensitive Data Exposure in 2017's neighbour list; a reader years later cannot tell which you meant.

• Always write the year. "A05:2025", never "A05" alone. The edition is part of the reference.
• State the edition once in the methodology, so every category tag in the report inherits it.
• Keep delivered reports as they were. A report delivered under 2021 is a record of what you found then, and should not be retro-fitted to 2025. Map new work to 2025 and leave the archive accurate to its date.
• Re-map the library, not the archive. Your reusable findings should track the current edition; your delivered reports should stay true to the edition they cited.

The broader point about what a reference in a report is for, and what belongs in one, is in what a penetration test report should contain.