OWASP Top 10 Explained – and Why the List Alone Won’t Keep You Secure

by Rebecca Sutton

The OWASP Top 10 ranks the most common and damaging security risks in web applications. OWASP, the nonprofit that maintains it, refreshed the list in late 2025, the first update since 2021. It is genuinely useful: a data-driven consensus, built from millions of real test results, on where applications keep failing. But it is not enough on its own to call an application secure. Treating it as a finish line, rather than a starting point, is where a lot of businesses go wrong.

What is the OWASP Top 10, really?

Strip away the branding and the OWASP Top 10 is a prioritised list of weakness categories. It is built from testing data covering more than 2.8 million applications. That data included roughly 175,000 mapped vulnerabilities, contributed by 13 security vendors. Twelve candidate categories were ranked from that data. Two more were then promoted, based on a practitioner survey. That is a sensible acknowledgement: raw testing numbers lag behind what security teams actually see in the field.

OWASP is explicit about what this is. It calls the list “a data-driven awareness document to help organizations prioritize”, not a certification scheme or a legal standard. Nobody passes or fails the OWASP Top 10. What you can do is test an application against it, then see how many of the ten categories turn up real findings.

The 2025 categories, ranked

Rank Category 2021 rank
A01 Broken Access Control 1st (SSRF, formerly A10, now folded in)
A02 Security Misconfiguration 5th
A03 Software Supply Chain Failures 6th (as Vulnerable and Outdated Components)
A04 Cryptographic Failures 2nd
A05 Injection 3rd
A06 Insecure Design 4th
A07 Authentication Failures 7th
A08 Software or Data Integrity Failures 8th
A09 Security Logging and Alerting Failures 9th
A10 Mishandling of Exceptional Conditions new

Two moves stand out here. Security misconfiguration climbed three places. And a brand-new category now covers exceptional conditions: applications that fail unsafely when pushed into edge cases nobody tested for. Neither is really about clever attackers. Both are about ordinary operational sloppiness: cloud settings left open, error handling nobody thought through.

Why the list changes every few years

Broken access control has stayed at number one for two editions running, and that tells its own story. It is the risk that affects the widest range of applications. An e-commerce site might let one customer see another’s orders. An internal tool might never check whether a “read-only” user could also write. Injection, by contrast, fell from third to fifth. That is not a sign SQL injection has stopped happening. OWASP puts it down to modern frameworks handling input sanitisation better by default. It is a rare example of the industry actually fixing something at scale.

The new supply chain category exists because the old “vulnerable and outdated components” framing missed the point. The risk is no longer just forgetting to update a library. It is a package or build pipeline being deliberately compromised. That is exactly what happened in the recent npm supply chain attack against Rollup’s developer tools. It is a fundamentally different problem to patch management, and it earned its own category.

Where the OWASP Top 10 falls short

Here is the part vendors selling automated scanning tools tend not to say out loud. The OWASP Top 10 is a list of categories, not a test plan for your specific application. Two applications can both have “broken access control” findings that look nothing alike, because access control logic is bespoke to your business rules. A generic checklist can flag that a control might be missing. It cannot tell you whether a three-year-old workaround your finance team built actually makes sense. It cannot tell you whether your logging would even notice someone abusing it.

The Top 10 also, by design, only covers the most common risks. Rare but severe issues, specific to your industry or architecture, can sit outside all ten categories entirely and still sink you. Treating “we tested against OWASP” as proof of security is exactly the kind of box-ticking the list was never meant to enable.

How a penetration test goes beyond the OWASP Top 10

A properly scoped web application penetration test uses the OWASP Top 10 as a starting checklist, not the whole exam. A skilled tester chains together minor findings across categories: an access control gap here, a misconfiguration there. Together they form an attack path no automated scanner would connect. That tester will also probe the business logic unique to your application, not just the generic patterns OWASP describes.

That distinction matters most for the two categories that jumped up the 2025 list. Security misconfiguration needs someone who understands how your specific cloud environment is set up, not a generic scan. Supply chain risk needs someone who will actually ask what is in your build pipeline, not just check whether your dependencies have a patch available.

What “awareness document” actually means for you

OWASP is careful with its own language, and it is worth taking that seriously rather than reading past it. An awareness document exists to get a risk noticed, not to certify that it has been eliminated. That is a different job to a standard like PCI DSS, which sets pass or fail requirements. It is also different to ISO 27001, which is something you get formally certified against.

The practical effect: two businesses can both say “we test against the OWASP Top 10” and mean very different things by it. One might run an automated scanner once a year and file the report. The other might commission a tester who manually probes access control logic, reviews how secrets are managed, and retests after fixes go in. Both statements are technically true. Only one reflects a serious security programme, and the difference rarely shows up until something actually goes wrong.

Ask what was actually done, not simply which list got referenced. A good report names the specific pages tested, the specific accounts used to probe access control, and the specific remediation steps taken. That tells you far more than a checkbox confirming coverage in the abstract.

Frequently asked questions

Should I only test against the OWASP Top 10?

No. Use it as a floor, not a ceiling. A good tester will cover the ten categories and go further into logic specific to your application.

Why did injection drop in the rankings if it’s still common?

The ranking reflects how often a category is found across tested applications, not how dangerous a single instance can be. Frameworks now block more injection attempts by default, so it turns up less often even though a successful attack can still be severe.

Is a higher rank always worse for my business?

Not necessarily. Rank reflects prevalence across all tested applications, not the specific risk to yours. An application handling no payment data, for example, may care less about certain cryptographic failure scenarios than one that does.

How do I know if my last test used the old 2021 categories?

Check the report date and its methodology reference. Anything scoped before late 2025 was almost certainly built against the 2021 list, so ask directly whether a retest would cover the new categories.

Close-up of a developer's screen reviewing application code as part of OWASP Top 10 testing

If you want a test that treats the OWASP Top 10 as a floor rather than the whole job, Aardwolf Security can help. We scope penetration tests around your actual application and business logic, not just a generic checklist. Get in touch to discuss what that looks like for you.

Subscribe to our newsletter

Honest updates, straight to your inbox. Unsubscribe any time.

You may also like