Two of the ten categories in the OWASP Top 10:2025 (the 2025 edition of the list) come not from testing data but from a survey of practitioners, and no black-box penetration test verifies them on its own. That detail, which summaries of the new edition tend to skip, changes what an audit report can and cannot prove. The edition, the first in four years, was unveiled in November 2025 and finalised in January 2026. The other changes: two new categories, one consolidation and a reshuffle that drops cryptography and injection two places each.
This article looks at the list from both sides of an engagement, the tester's and the buyer's: what a pentester checks in each category and which ones can only be verified with access to the code, the build chain or the defence team in the room. That points to what should change in the scope of the next web application security audit so the report covers the whole list and not just the categories that can be tested from outside. We covered what separates the Top 10 from the WSTG testing guide in penetration testing methodologies; that distinction is taken as read here.
How the OWASP Top 10:2025 differs from 2021
The official introduction sets out the moves. Broken Access Control stays first, now with Server-Side Request Forgery (SSRF) folded into it. Security Misconfiguration climbs from fifth to second. Software Supply Chain Failures is new at third: it widens the old "Vulnerable and Outdated Components" to the whole ecosystem of dependencies, build systems and distribution.
Cryptographic Failures drops from second to fourth and Injection from third to fifth. Insecure Design slips to sixth. Authentication Failures (A07), Software or Data Integrity Failures (A08) and Security Logging and Alerting Failures (A09) keep their places; A07 and A09 get new names. The tenth is new: Mishandling of Exceptional Conditions.
The numbers behind the list matter as much as the order. The data comes from more than 2.8 million applications contributed by twelve named organisations and anonymous contributors. OWASP analysed 589 weaknesses from the CWE catalogue, up from around 400 in 2021, and the ten categories group 248 of them, capped at 40 per category.
Eight categories come from the data and two were chosen by the community survey, for a reason the authors state plainly: data looks backwards, because a weakness takes weeks or years to get reliable automated tests, and some may never get them.
Two OWASP Top 10 2025 categories come from a survey, and that changes your pentest report
The two voted categories are the supply chain (A03) and logging and alerting (A09). The first received the most votes, with half of respondents ranking it first. Even so, it is the category with the fewest occurrences in the data: only 11 CVEs tied to its weaknesses, a scarcity the authors put down to how hard it is to test.
When it is tested, it shows the highest average incidence rate, above 5% of applications, and the highest average exploitability and impact scores in the whole list. Logging and alerting (A09) tends to be under-represented by its very nature: a log that is missing produces no finding.
For anyone commissioning an audit the implication is straightforward. A black-box penetration test of a production application will not find supply chain or alerting failures except by accident, because they seldom show up in an HTTP request. If the last audit report says nothing about either category, that does not mean the application is clean; it means nobody looked. And that gap is exactly what the community flagged by voting those two categories in.
What a web pentest covers in the OWASP Top 10 2025, category by category
Categories a web pentest covers well
Access control (A01) is the category where a pentest pays off most and the one with the most occurrences in the data: direct references to other users' objects, forced browsing to admin pages, controls enforced only in the browser, tampering with JWT tokens or cookies, over-permissive CORS origins. The classic test still holds: two accounts with different roles, checked in both directions so that neither reaches what it should not, including the API's POST, PUT and DELETE verbs.
Configuration (A02), cryptography (A04) and injection (A05) also test well from outside, with caveats. On injection, OWASP itself notes the asymmetry: cross-site scripting is frequent and low impact; SQL injection is rare and high impact. A report with twenty XSS findings and no SQLi does not mean the application is worse off than one with a single SQL injection. Authentication (A07) is tested with the usual techniques, and here the Top 10 offers an encouraging note: the increased use of standardised authentication frameworks appears to be having beneficial effects.
The other new category, Mishandling of Exceptional Conditions (A10), groups 24 weaknesses: error messages that leak internal detail, missing or extra parameters handled badly, uncaught exceptions, controls that fail open and transactions that are not fully rolled back. A pentester triggers them deliberately: sends requests without a mandatory parameter, forces database errors to see what the server returns, interrupts a multi-step operation halfway through. Several of these weaknesses were previously associated with "poor code quality", as OWASP acknowledges; now they have a category of their own.
Categories that require the code or the build chain
The supply chain (A03) is verified through inventory rather than requests: a centrally generated SBOM, software composition analysis that covers transitive dependencies, and a review of how the artefact is built and shipped.
The document widens the scope compared with 2021. It asks for a review of the code repository, developer workstations, the build server, container registries and IDE extensions. It also asks for separation of duties: nobody should be able to write code and promote it all the way to production without oversight from another person. That scope does not fit a web pentest; it fits a source code security audit or a DevSecOps review. Among the examples OWASP cites is the 2025 Shai-Hulud npm worm, whose later variant we analysed in the self-replicating npm worm.
Insecure Design (A06) and Software or Data Integrity Failures (A08) fall somewhere in between. A pentester spots symptoms of insecure design (business logic that lets you order a hundred units at a negative price) but cannot verify that threat modelling ever happened; that is reviewed through documentation and interviews. Integrity is partly testable from outside (unsigned updates, deserialisation of untrusted data) and the rest from inside (the integrity of the continuous integration chain).
Logging and alerting (A09): only a coordinated test verifies it
The new name of logging and alerting (A09) points to a specific idea: OWASP stresses that great logging with no alerting is of minimal value. The most direct way to verify this category is to coordinate the test with whoever is watching: the pentester runs actions that should raise an alert (brute force against the sign-in, repeated access control failures, an escalation). The defence team then checks what reached the SIEM and which rules fired.
It is the same principle we applied in detection engineering: coverage on paper does not predict detection. A pentest without that coordination leaves the category unverified, and the report should say so.
How to read a pentest report against the Top 10 2025 categories
The underlying methodological change is the shift to root cause over symptom. The authors explain that "sensitive data exposure" or "denial of service" are symptoms, while "cryptographic failure" or "misconfiguration" are causes, and that the list was reorganised to give better identification and remediation guidance.
For the reader of a report, the practical consequence is that the category label says less than the CWE identifier: with 248 weaknesses spread over ten buckets, a pair of findings under A01 can be a trivial IDOR and an SSRF into the internal network. Ask for the CWE and the CVSS on every finding and read severity from there; we covered how to interpret those fields in how to read a penetration testing report.
The second consequence is that the 2021 to 2025 mapping is not one to one. An SSRF finding from 2023 sat under A10; today it sits under A01. An "outdated component" from 2022 was A06; today it is A03 with a far wider scope. If you compare reports from different years by category, fix the mapping first or the comparison is meaningless.
What to add to the scope of your next web audit
In practice, the Top 10:2025 tells the buyer that a black-box test can cover six categories well (one of them, A10, only if the scope names it expressly), partly covers two and covers neither of the two the community voted in, on its own. Completing the list does not require a different service; it requires naming the missing pieces in the engagement: a dependency and build chain review with an SBOM, a coordinated session with the defence team to validate alerting, and an explicit block of error-handling and interrupted-transaction tests.
At Hard2bit Cybersecurity that conversation about scope happens before signing, not when the report lands, because a pentest that returns "no findings" in a category nobody tested is worse than one that leaves it out and says so. If the application exposes APIs, the API security audit has its own criteria, which overlap with the Top 10 only in part.
Limits of the Top 10 worth keeping in mind
The document describes itself as an awareness document. To verify an application rigorously, OWASP points to the ASVS and the WSTG testing guide, which go down to specific requirements and test cases.
The data also carries biases OWASP acknowledges. It measures prevalence per application, so an application with 4 or with 4,000 instances of a weakness counts the same. It depends on what tools know how to test. And exploitability and impact scores are computed with CVSS v2 and v3, because v4 no longer separates the two. It is an excellent list for prioritising and for talking to the board, and a poor checklist to audit against.
Hard2bit has audited web applications and APIs since 2013 with the OWASP Top 10 as the minimum and the WSTG as the reference for test cases, and holds Spain's ENS (National Security Framework) High-category certification and five ISO standards, including ISO 27001:2022.
This analysis is provided for informational purposes and reflects the content of the OWASP Top 10:2025 on its publication date; OWASP may correct figures or wording in later revisions, so always check against the official document. The tests and scoping criteria described are indicative and must be adapted to each application and its context; they do not replace an audit of your environment. If you want to define the scope of a web or API audit against the 2025 categories, you can talk to the Hard2bit team.
Frequently asked questions
Which categories are new in the OWASP Top 10 2025?
▾
Two: Software Supply Chain Failures (A03), which widens the old vulnerable and outdated components category to dependencies, build systems and distribution, and Mishandling of Exceptional Conditions (A10), which groups 24 weaknesses around error handling, failing open and transactions that are not rolled back. SSRF also stops being its own category and becomes part of Broken Access Control (A01).
Why is the supply chain ranked third if it barely appears in the data?
▾
Because the Top 10 reserves two places for the community survey, and the supply chain was the top vote, with half of respondents ranking it first. In the data it has only 11 associated CVEs, which OWASP attributes to how hard it is to test; when it is tested, it shows the highest average incidence rate and the highest exploitability and impact scores in the list.
Does a web pentest cover the whole OWASP Top 10 2025?
▾
No. A black-box test covers six categories well (access control, configuration, cryptography, injection, authentication and exceptional conditions, the last one provided the scope names it), partly covers two (insecure design and integrity) and cannot cover two on its own. Supply chain and logging and alerting seldom show up in HTTP requests: the first needs a dependency inventory and a build chain review, the second a test coordinated with the defence team.
How is the logging and alerting category tested in an audit?
▾
By coordinating the test with whoever is watching: the auditor runs actions that should raise an alert, such as brute force against the sign-in, repeated access control failures or a privilege escalation, and the defence team checks what reached the SIEM and which rules fired.
What are the 10 categories of the OWASP Top 10 2025?
▾
A01 Broken Access Control (now including SSRF), 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, and A10 Mishandling of Exceptional Conditions. Together they group 248 CWE weaknesses, capped at 40 per category.
Can pentest reports from 2021 and 2025 be compared by category?
▾
Only after correcting the mapping. SSRF was A10 in 2021 and now sits inside A01; outdated components were A06 and are now A03 with a much wider scope; cryptography and injection have each dropped two places. Comparing by CWE is more reliable than comparing by category.
When was the OWASP Top 10 2025 published?
▾
It was unveiled in November 2025 and the final version was published in January 2026. It is the eighth edition of the list and the first since 2021, which it replaces as the reference list.
Is the OWASP Top 10 a standard to audit against?
▾
OWASP defines it as an awareness document. To verify an application rigorously it points to the ASVS, which sets verifiable requirements by level, and to the WSTG testing guide, which goes down to specific test cases.
