The OWASP Top 10 is a ranked list of the ten most critical security risks to web applications, published by the Open Worldwide Application Security Project (OWASP). The current edition is the 2025 list, led by broken access control. OWASP calls it an awareness document, so a pen test that “covers the OWASP Top 10” still needs a proper scope.
That last sentence is the one worth holding on to. Almost every web application testing proposal you’ll ever receive mentions the OWASP Top 10, usually in the first paragraph, often in bold. Ours included. The phrase tells you what a tester will be thinking about. It doesn’t tell you what they’ll actually do.
This guide is written for the person signing off the test rather than the person running it. If you want the wider picture first, our penetration testing overview covers what we test and why.
What the OWASP Top 10 Is and Who Publishes It
The OWASP Top 10 is a consensus list of web application risks, built from real testing data and a community survey, and refreshed every few years.
OWASP is a nonprofit foundation that, in its own words, “works to improve the security of software” (About OWASP (opens in a new tab)). Its best-known project is the Top 10, which it describes as “a standard awareness document for developers and web application security” (OWASP Top 10:2025 (opens in a new tab)).
The 2025 edition was built from data on more than 2.8 million applications, donated by the organisations that test them (OWASP Top 10:2025 introduction (opens in a new tab)). Only eight of the ten categories come from that data. OWASP takes the other two from a community survey, because, in its own words, the data is “incomplete”. That is refreshingly honest, and it matters to a buyer: two of the ten were chosen by practitioners’ judgement, not by counting.
The previous edition was 2021. Both are still live on OWASP’s site, and you’ll see both quoted in proposals and reports for a while yet.
The OWASP Top 10 2025 List in Plain English
The 2025 list runs from broken access control at number one to mishandling of exceptional conditions at number ten. Names are exactly as OWASP writes them; the rest is ours.
| ID | Category | What it means for your application | How a tester looks for it |
|---|---|---|---|
| A01:2025 | Broken Access Control | Users can see or do things outside their permissions, such as reading another customer’s invoice by changing a number in the address bar | Logs in as different users and roles and tries to cross the lines between them |
| A02:2025 | Security Misconfiguration | Defaults left on, admin pages exposed, error messages that say far too much | Scanners catch a lot of this; the tester confirms what matters and what it leads to |
| A03:2025 | Software Supply Chain Failures | Weak or compromised third-party code, tools or update processes that your application relies on | Identifies outdated or vulnerable components visible from the outside; the build pipeline itself usually needs a separate review |
| A04:2025 | Cryptographic Failures | Sensitive data sent or stored without adequate protection | Checks how passwords, tokens and personal data are transmitted and, where visible, stored |
| A05:2025 | Injection | Input from a user gets treated as a command, as in SQL injection | Tests every input the application accepts, by hand and with tooling |
| A06:2025 | Insecure Design | A control that was never designed in, so no amount of careful coding would have added it | Business logic testing finds the symptoms; the fix is usually a design conversation |
| A07:2025 | Authentication Failures | Weak login, password reset or session handling | Works through login, reset, lockout and session behaviour |
| A08:2025 | Software or Data Integrity Failures | The application trusts code or data without checking where it came from | Looks at how updates, plugins and data passed between components are trusted, where they’re reachable |
| A09:2025 | Security Logging and Alerting Failures | Attacks happen and nobody is told | Rarely proven by the test itself; ask afterwards whether anyone noticed the tester |
| A10:2025 | Mishandling of Exceptional Conditions | The application fails badly under unusual input: it crashes, leaks detail or fails open | Feeds it malformed and unexpected input and watches how it breaks |
Broken access control earns its place at the top. OWASP reports that “100% of the applications tested were found to have some form of broken access control” in the contributed data (A01:2025 (opens in a new tab)). Every one. That figure comes from applications that were tested, which skews it, but I’ve yet to meet a buyer who believed their application was the exception and turned out to be right.
It is also the category a scanner is worst at. A scanner doesn’t know that user A shouldn’t see user B’s orders. A person does.
What Changed Between the 2021 and 2025 Editions
The 2025 edition added one new category, broadened another and absorbed a third, so a report or proposal still quoting 2021 is working from an out-of-date list.
| Change | 2021 | 2025 |
|---|---|---|
| New category | — | A10:2025 Mishandling of Exceptional Conditions, “a new category for 2025” |
| Broadened | A06:2021 Vulnerable and Outdated Components | A03:2025 Software Supply Chain Failures, “an expansion” of the 2021 category |
| Absorbed | A10:2021 Server Side Request Forgery (SSRF) was its own category | SSRF “has been rolled into” A01:2025 Broken Access Control |
| Moved up | Security Misconfiguration at number 5 | Number 2 |
| Moved down | Cryptographic Failures at 2, Injection at 3, Insecure Design at 4 | Numbers 4, 5 and 6 |
All quotations and positions are from the 2025 introduction (opens in a new tab); the 2021 IDs are from the 2021 list (opens in a new tab).
The practical point is small but useful. If a proposal you received this year talks about testing against “the OWASP Top 10 2021”, ask why. There may be a good answer. There may just be an old template.
How the OWASP Top 10 Shows Up When You Buy a Penetration Test
The OWASP Top 10 should shape the scope, the method and the report of a web application penetration test, and you can check all three before you sign.
In the scope. Most of the list can only be tested properly once the tester is logged in. Broken access control, the number one risk, is almost invisible from the login page. So the question that matters is not “do you test the OWASP Top 10?” but “will you test as an authenticated user, and with how many roles?” A customer portal with customers, staff and administrators needs all three accounts, set up before the tester starts.
In the method. Expect a mix of automated tooling and manual work, and expect the proposal to say which is which. The categories near the top of the list are the ones that need a person.
In the report. A good report maps each finding to the category it belongs to and tells you how it was demonstrated, not just that a tool flagged it. If every finding in the report came straight out of a scanner, you’ve bought a scan. We’ve written more about the difference between a vulnerability scan and a penetration test.
Think of it like the list of the most common reasons cars fail their MOT. Very useful. It tells the garage where to look first. But nobody would accept “we checked the top ten reasons” in place of the MOT itself.
Why “OWASP Top 10 Compliant” Doesn’t Mean Much
No application is “OWASP Top 10 compliant”, because OWASP never wrote the Top 10 to be complied with.
OWASP is unusually direct about this. The 2021 edition’s guidance on using the list says “the OWASP Top 10 is primarily an awareness document” and that “tools cannot comprehensively detect, test, or protect against the OWASP Top 10 due to the nature of several of the OWASP Top 10 risks” (How to use the OWASP Top 10 as a standard (opens in a new tab)). It goes on to say the list documents risks, “and not necessarily easily testable issues”.
Insecure design is the clearest case. OWASP’s 2025 description puts it bluntly: “An insecure design cannot be fixed by a perfect implementation as needed security controls were never created to defend against specific attacks” (A06:2025 (opens in a new tab)). A tester can find the symptoms. A tester can’t design the missing control for you. That is a design review, and it’s cheaper before the code is written than after.
So when a supplier, a customer or a board member asks whether you’re “OWASP compliant”, the honest answer is that the question doesn’t quite work. The better answer is what was tested, how, and against which list.
The question most buyers really mean is “are we covered?” The OWASP Top 10 won’t tell you. A well-scoped test will tell you a great deal more.
Where the OWASP Top 10 Stops and Other OWASP Lists Take Over
The OWASP Top 10 covers web applications. APIs, large language model applications and formal verification each have their own OWASP document, and a good test will use the one that fits what you’ve built.
| If you need… | Use | What it is |
|---|---|---|
| A standard you can actually verify against | OWASP Application Security Verification Standard (ASVS) (opens in a new tab) | A project that “provides a basis for testing web application technical security controls”, in OWASP’s words, and the document OWASP itself recommends to anyone “wanting to adopt an application security standard” |
| Coverage for an API | OWASP API Security Top 10 (opens in a new tab) (2023 edition) | The API equivalent of the Top 10; the NCSC points to it in its guidance on building and operating a secure online service (opens in a new tab) (published 2 March 2022) |
| Coverage for a chatbot or other LLM application | OWASP Top 10 for LLM Applications (opens in a new tab) (2025 edition) | A separate list, led by prompt injection |
If your web application is really a front end on an API, the API list matters as much as the web list. Our API penetration testing covers that side. We’ve also gone through the API list risk by risk in our post on API security testing. If there’s a language model anywhere in the product, the LLM list applies too, and we’ve written separately about prompt injection and LLM penetration testing.
The NCSC’s own line on the Top 10 is worth quoting, because it’s the right framing for a buyer: it “offers a view of the most common attacks in this space, defending against these should be considered throughout the development of the system”. Throughout the development. Not once a year, the week before a customer asks for a report.
OWASP Top 10 FAQs
What Does OWASP Stand For?
OWASP stands for the Open Worldwide Application Security Project, a nonprofit foundation that publishes free guidance on software security, including the OWASP Top 10.
What Is the Latest Version of the OWASP Top 10?
The latest version is the OWASP Top 10 2025. OWASP’s project page (opens in a new tab) states that “the most current released version is the OWASP Top 10 2025”. The previous edition was 2021.
Is the OWASP Top 10 Updated Every Year?
No. The OWASP Top 10 is updated every few years rather than annually. The 2025 edition replaced the 2021 edition, so the 2025 list is still the current one.
What Is the Number One Risk in the OWASP Top 10?
Broken access control is the number one risk in the OWASP Top 10 2025, as it was in 2021. It means users can see or do things outside their intended permissions.
Can a Vulnerability Scanner Test for the OWASP Top 10?
Only partly. A scanner can flag many misconfiguration, injection and outdated-component issues, but OWASP says tools cannot comprehensively detect the Top 10, and access control and design flaws need a person.
Is the OWASP Top 10 a Compliance Standard?
No. OWASP describes the Top 10 as an awareness document and recommends its Application Security Verification Standard (ASVS) to anyone who needs a standard to test and verify against.
What to Ask for in Your Next Web Application Test
Ask for the edition, the accounts and the method, in writing, before the test starts.
Which edition of the OWASP Top 10 is the tester working to, and if it’s not 2025, why not? Will they test as an authenticated user, and with which roles? Which categories are covered by hand, and which by tooling? And what do they expect not to be able to test, such as insecure design or your logging, so that you know where the gaps are before the report lands rather than after.
I’ve read a good many pen testing proposals over the years, and far fewer of them answer those four questions than you’d hope. If you’d like a second opinion on one you’ve been sent, or want to talk through scoping a test of your own, do get in touch.
The OWASP Top 10 isn’t a test. It’s a list of the places a good test should look.