What the 2025 OWASP Top 10 ranking actually measures

The eighth OWASP Top 10 landed at Global AppSec in November 2025 and was finalised in January 2026. It is the first revision since 2021, and it is the document your customers, auditors and security questionnaires will point at for the next three or four years.

Most write-ups stop at the reordered list. The interesting part is underneath it, in the numbers OWASP publishes alongside each category, because those numbers do not say what the ranking implies they say.

What moved

Nine of the 2021 categories survive in some form. One was merged away, one is genuinely new, and three were renamed. The renames are not cosmetic. Each one narrows or widens what the category is asking you to test.

Security Misconfiguration climbing from fifth to second is the biggest move. OWASP’s explanation is short and correct: more and more of an application’s behaviour is decided by configuration rather than code, so more of its security is too.

Rank is not prevalence

Here is the first thing the ranking hides. If you sort the ten categories by how often they were actually found, the order is not the Top 10 order. It is not close to it.

The highest average incidence rate on the list belongs to A03, ranked third. The second highest belongs to A09, ranked ninth. A01, ranked first, is fourth by this measure. Insecure Design, ranked sixth, is the rarest thing on the list at 1.86%.

That is not a flaw in the methodology, and it is worth understanding why. Ranking blends four things: how often a weakness is found, how many applications were even tested for it, and the average exploitability and impact scores of the CVEs mapped to it. Two of the ten slots are then handed to the community survey outright, on the reasoning that the data can only ever describe what the industry already knows how to test for.

The detectability gap

The second thing the ranking hides is much starker. Count the CVEs mapped to each category’s CWEs and the spread runs across four orders of magnitude.

Injection has 62,445 CVEs. Software Supply Chain Failures has eleven. Nobody believes supply chain risk is five thousand times smaller than injection risk. Half of the community survey respondents ranked it the single biggest concern on the list, which is how it reached third place with the fewest occurrences in the entire dataset.

The gap is a measurement artefact. Injection is trivially automatable, so thirty years of scanners have generated an enormous CVE corpus. Supply chain compromise is hard to test for, so it barely appears, while carrying the highest average exploit score (8.17) and the highest average impact score (5.23) of any category on the list. Rare in the data, worst when it happens.

A category with no findings against it usually means nobody looked, not that nothing is there.

A03, and what testing it actually means

A03 is an expansion of 2021’s Vulnerable and Outdated Components, and the expansion is the whole point. The old category meant: run a dependency scanner, patch what it flags, move on. A03 covers the build system, the package registry, the CI runner, the signing keys, the actions and plugins your pipeline pulls at build time, and every human with commit access to any of it.

That is harder to test and much harder to fix, because most of it sits outside the application you commissioned a test for. When a client asks us to cover A03 properly, the scope stops being a URL and starts being a pipeline.

A10 is not about stack traces

Mishandling of Exceptional Conditions is new, carries 24 CWEs, and will be widely misread as “stop leaking stack traces”. Leaking a stack trace on a 500 is part of it and it is the cheap part. The expensive part is what your code decides to do when something it depends on fails.

try:
    allowed = authz.check(user, resource)
except AuthzServiceTimeout:
    # the authorisation service was slow, so we carried on
    allowed = True

if allowed:
    return resource.data

Nobody writes that on purpose. It arrives during an incident, when the authorisation service was flapping and the change that stopped the pager going off was to stop treating a timeout as a denial. Then it ships, and the way to bypass authorisation becomes: make one service slow.

A10 has 20.67% max incidence, meaning some contributors found it in one application in five. It is not a rare or theoretical category.

Where SSRF went

SSRF had its own slot at A10 in 2021. It does not have one now. It sits inside A01 as CWE-918, on the reasoning that persuading a server to fetch a URL it should not fetch is an access-control failure wearing a different hat.

The reasoning is sound. The practical risk is that SSRF quietly drops off scoping conversations because it is no longer a line item. If your report template enumerated the 2021 categories, check that SSRF survived the migration. We test for it either way, and we still find it, most often in the same three places: webhook configuration, document and image fetchers, and any feature that accepts a URL for “import from”.

What this changes about a penetration test

Less than you would think, and any vendor claiming their methodology has been transformed is selling you a rewritten proposal. The Top 10 is a set of awareness categories, not a test plan. It has never been the thing that tells a tester what to try next. That job belongs to OWASP ASVS, to the WSTG, and to a person who understands what your application is for.

• Map findings to the 2025 identifiers. An auditor comparing against the current list will ask why your report cites a five-year-old edition.
• Scope supply chain explicitly. It is now a named category, which makes it something you can buy rather than something everyone assumed was somebody else’s problem.
• Write test cases for fail-open error paths. A10 finally gives you a category to file them under.
• Read incidence rates as coverage, not risk. A low number can mean the weakness is rare, or that almost nobody tested for it.
• Check that SSRF is still named somewhere in your scope, now that it is not its own entry.

One thing the list still will not do

It will not tell you whether one of your customers can read another one’s data. Tenant isolation is the finding we report most often, it sits squarely inside A01, and no amount of category-mapping will surface it. Only two accounts and somebody who knows which identifier means what will do that.

Use the Top 10 to check your coverage for obvious holes and to speak the same language as your auditor. Do not use it as the definition of done.