OWASP Top 10 2025: What Changed and What to Ask Your Penetration Tester

If your last web application penetration test report mentioned “OWASP”, it was almost certainly measuring your application against the OWASP Top 10. That is the industry’s most widely used ranking of critical web application risks. OWASP published its first full revision of that list since 2021 in January 2026. The changes are big enough that a test scoped against the old version will miss things a modern one should catch.

What the OWASP Top 10 Actually Is

OWASP, the Open Worldwide Application Security Project, is a non-profit. It has published this list roughly every three to four years since 2003. Each edition ranks the ten vulnerability categories doing the most damage across real-world applications. It draws on contributed testing data and a practitioner survey. The 2025 edition used the largest dataset yet: testing data from thirteen organisations across roughly 2.8 million applications. That data was mapped to about 175,000 CVE records spanning 589 distinct weakness types.

It is not a checklist you tick off once. It is a shared reference point. When a penetration tester writes “A01” in a report, every reader familiar with the OWASP Top 10 knows what that means straight away. No paragraph of explanation needed.

What a Tester Should Change After This Update

Two categories are entirely new. One long-standing category effectively disappeared into another. Both matter for scoping.

Software supply chain failures now has its own line item

The old “vulnerable and outdated components” category has been rebuilt into something far broader. Software Supply Chain Failures covers compromised open-source packages, tampered build pipelines and hijacked vendor update mechanisms. It goes well beyond known CVEs sitting in outdated libraries. The 2019 SolarWinds incident is the case OWASP itself points to: a poisoned vendor update that compromised roughly 18,000 organisations. Aardwolf wrote about a more recent version of the same problem when the Shai-Hulud worm spread through npm by hijacking package install scripts. A test that only checks your code for known CVEs is testing against the old category. It needs to ask how your dependencies get built and updated too.

A new category for how your application fails, not just how it is attacked

Mishandling of Exceptional Conditions is brand new for 2025. It covers what happens when an application hits a timeout or a malformed input. It also covers error states nobody built the application to handle. OWASP co-lead Tanya Janca has explained the reasoning plainly. Telling a developer “your code is bad, do better” was never something they could act on. The list now names a specific class of failure to look for instead.

Server-Side Request Forgery lost its own category

SSRF stood alone as its own category in 2021. It is now folded into Broken Access Control. At its core, an SSRF flaw is an authorisation problem. It just happens to route through a server-side request rather than a distinct bug class.

Where Each Category Sits Now

• A01 Broken Access Control: still #1, and OWASP’s own data suggests it affects around 3.73% of tested applications.
• A02 Security Misconfiguration: jumped from #5 to #2, largely a cloud and container problem now.
• A03 Software Supply Chain Failures: new, replacing the old components category.
• A04 Cryptographic Failures: fell from #2 to #4 as TLS adoption has improved industry-wide.
• A05 Injection: fell from #3 to #5, though it remains common in anything still built on unparameterised queries.
• A06 Insecure Design: architecture-level flaws that no amount of secure coding can retrofit away.
• A07 Authentication Failures: renamed from “Identification and Authentication Failures”, same substance.
• A08 Software or Data Integrity Failures: renamed to treat software and data integrity as separate concerns.
• A09 Security Logging and Alerting Failures: renamed from “Monitoring” to stress action over passive logs.
• A10 Mishandling of Exceptional Conditions: entirely new, covering error states and edge cases.

What This Means for Scope, Time and Cost

A test scoped against the 2025 categories is not necessarily longer or more expensive than one scoped against 2021. But it does need to cover different ground. Checking software supply chain failures properly means the tester needs an accurate inventory first. That means your dependencies, your build tooling and your update mechanisms, before testing even starts. Many organisations have never had that scoping conversation. Skipping it is the most common way a test ends up quietly stuck on the old list without anyone noticing.

Exceptional-conditions testing works differently again. It leans on deliberately feeding an application malformed input, forced timeouts and edge-case data, then watching how it degrades. That takes more tester time per feature than a straightforward access-control check. If a quote looks identical to what you paid in 2023 for the same scope, ask why. Find out whether the newer categories were actually priced in, or simply left out.

Questions Worth Asking Your Next Penetration Testing Provider

Before you commission a web application penetration test, confirm the methodology reflects the current list rather than the 2021 version. This matters most if your applications rely heavily on third-party packages, containers or cloud infrastructure. That is where most of this year’s movement happened.

• Does the proposal reference the 2025 categories by name, or does it still cite the 2021 list?
• How does the tester assess software supply chain risk, beyond a simple CVE scan of your dependencies?
• Will the report map findings back to specific OWASP categories, so you can track progress year over year?
• How much of the engagement is manual testing rather than automated scanning? Chained business logic issues, the kind that cause the most damage, rarely show up in a scanner report alone.

A properly scoped test should treat the OWASP Top 10 as a floor, not a ceiling. Automated tools cover the list reasonably well now. The value a skilled tester adds is finding the application-specific logic flaws that sit outside any generic ranking.

If you would rather get a straight answer than guess, Aardwolf Security’s penetration testing team can check whether your last report actually covered the current categories. Get in touch and we will tell you plainly what, if anything, needs retesting.

Frequently Asked Questions

Do I need to fix every OWASP Top 10 category to be considered secure?

No. The list ranks the most prevalent risk categories across a huge dataset of applications. It is not a complete inventory of every risk your specific application faces. Business logic flaws unique to how your application works will never appear on a generic list.

Is the OWASP Top 10 a compliance standard?

Not on its own. Frameworks like PCI DSS reference it as a secure coding benchmark. There is no certificate for passing the OWASP Top 10 itself.

How is the list actually compiled?

Mostly from contributed testing data across a large pool of real applications, weighted by CVSS exploit and impact scores. A practitioner survey fills the gaps, catching risks like emerging supply chain attack patterns that the raw data cannot see yet.

Why did it take four years to update?

OWASP wanted a substantially larger dataset before publishing again. The 2025 edition analysed roughly 175,000 CVEs against 589 weakness types. That is up from around 125,000 CVEs and 400 weakness types in 2021.

What should change in how I brief my development team?

Ask which categories your CI pipeline already tests for automatically, and which ones only ever get caught by a human tester. Supply chain and exceptional-conditions failures are the two categories least likely to be caught by automated tooling alone.