In short
The OWASP Top 10 are a regularly updated awareness document from the Open Worldwide Application Security Project that summarises the ten most critical security risks for web applications in categories and thus sets a globally recognised minimum standard for application security.
The Open Worldwide Application Security Project (until 2023 the Open Web Application Security Project) is a non-profit foundation that publishes freely available standards, tools and documentation on software security. The Top 10 are its best-known product. They are not published annually but at intervals of several years; the 2025 edition is the eighth edition of the list.
Decisive for understanding it correctly: the OWASP Top 10 are not an audit catalogue or a certification standard. They are an awareness document. Anyone who needs a complete, verifiable list of requirements turns to the more advanced OWASP projects, which are distinguished below.
How the list is created
In OWASP's own words, the methodology is data-informed but not purely data-driven. For the 2025 edition, organisations such as Veracode, Contrast Security, Sonar, Semgrep, Bugcrowd, Probely, Orca Security, Wallarm, CryptoNet Labs, Accenture and usd AG contributed test results from more than 2.8 million applications.
What is measured is not the frequency of individual findings but the incidence rate: what proportion of the applications tested have at least one instance of a particular class of weakness? This decision prevents automated scanners with thousands of individual reports from distorting the picture while manual testers record the same weakness only once.
MITRE's Common Weakness Enumerations (CWE) serve as the vocabulary. For the 2025 edition, 589 CWEs were evaluated, compared with around 400 in the 2021 edition and about 30 in 2017. 248 of them are assigned to the ten categories, with a maximum of 40 CWEs per category. Exploitability and impact values come from CVSS ratings of the CVEs listed in the National Vulnerability Database.
Eight of the ten places result from the data. Two further places are allocated via a community survey. The reasoning behind this is remarkable and explains a lot about the nature of the list: test data always describes the past. It takes years before a new class of weakness is understood, integrated into tools and widely measured. Some risks can never be measured reliably by automated means at all. The survey lets practitioners contribute the risks they see in practice before they become visible in the data.
The categories of the 2025 edition
- A01:2025 – Broken Access Control: still in first place. On average, 3.73% of the applications tested had at least one of the 40 CWEs in this category. Server-side request forgery, still a separate category in 2021, has been incorporated here.
- A02:2025 – Security Misconfiguration: up from fifth place. 3.00% of applications affected, 16 CWEs. OWASP explains the rise by the fact that ever larger parts of application behaviour are controlled via configuration rather than code.
- A03:2025 – Software Supply Chain Failures: new. Extends the former category "vulnerable and outdated components" to the entire ecosystem of dependencies, build systems and distribution infrastructure. Rarely represented in the data, but with the highest average exploit and impact values and overwhelmingly named as the top concern in the community survey.
- A04:2025 – Cryptographic Failures: down from second to fourth place. 3.80% of applications, 32 CWEs.
- A05:2025 – Injection: down from third to fifth place. 38 CWEs, including cross-site scripting (frequent, lower individual damage) and SQL injection (less frequent, high damage). The category with the most assigned CVEs.
- A06:2025 – Insecure Design: down from fourth to sixth place. OWASP attributes the decline to measurable progress in threat modelling.
- A07:2025 – Authentication Failures: renamed from "identification and authentication failures", unchanged in seventh place, 36 CWEs. The widespread use of standardised authentication frameworks is having an effect.
- A08:2025 – Software or Data Integrity Failures: violated integrity of software, code and data artefacts at a lower level than A03.
- A09:2025 – Security Logging & Alerting Failures: renamed from "logging and monitoring failures". The change of name emphasises alerting: logging without alerting is of little use for detecting incidents.
- A10:2025 – Mishandling of Exceptional Conditions: new. 24 CWEs relating to poor error handling, logical errors and systems that fail open rather than fail safe in exceptional situations.
What has changed compared with 2021
The 2021 edition comprised: broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable and outdated components, identification and authentication failures, software and data integrity failures, security logging and monitoring failures, and server-side request forgery.
| Change | Content |
|---|---|
| Two new categories | Software supply chain failures (A03) and mishandling of exceptional conditions (A10) |
| One consolidation | Server-side request forgery was merged into broken access control |
| One extension | "Vulnerable and outdated components" was expanded into software supply chain failures |
| Two renamings | Authentication failures; security logging & alerting failures |
| Changes in rank | Misconfiguration moved up; cryptographic failures, injection and insecure design moved down |
The direction is clear: away from the individual line of code, towards configuration, supply chain and operation. This reflects the reality of modern applications, in which the vast majority of the code delivered comes from third-party dependencies.
Distinction from other OWASP projects
The Top 10 are regularly confused with documents that serve a different purpose.
- OWASP ASVS (Application Security Verification Standard) is the verification standard. It formulates hundreds of concrete, testable requirements at graded security levels. Where the Top 10 create awareness, the ASVS provides the acceptance criteria. It is the more reliable basis for contracts and security audits.
- OWASP API Security Top 10 is a separate list for interfaces. It covers risks that weigh differently for pure API back ends than for classic web interfaces, such as object-level authorisation or missing rate limiting.
- OWASP Mobile Top 10 and other derived lists deal with mobile applications and related fields. A separate risk list exists for applications with language models.
- OWASP Cheat Sheet Series and the Web Security Testing Guide provide the practical implementation: instructions per topic and a testing methodology.
A sensible division of labour looks like this: the Top 10 serve to raise awareness and as an entry grid in training, the ASVS defines the binding requirements, and the testing guide describes the testing.
Role in tenders and acceptance
In service specifications and requirement documents, the wording "development according to the OWASP Top 10" appears very frequently. It is well meant but imprecise both legally and technically, because the Top 10 contain no verifiable requirements. A statement such as "the application is OWASP Top 10 compliant" cannot be proven objectively.
Wording that names the testing benchmark is more reliable. The following building blocks have proven themselves:
- Reference to a specific ASVS level instead of to the Top 10 across the board.
- An obligation to carry out automated dependency checks in the build pipeline with a defined response time for critical findings.
- Naming the testing methodology, for example according to the OWASP Web Security Testing Guide, together with the time of acceptance.
- Rules on who fixes findings from a penetration test and within what period, with classification by severity.
- Requirements for logging and alerting on security-relevant events, the point most frequently overlooked in practice.
For the procurement side, it is also relevant that the Top 10 are limited to the application level. Operational security, network segmentation, identity management and organisational measures do not fall under them and must be regulated separately.
Relevance for e-commerce and B2B at mid-sized companies
Online shops and B2B portals combine exactly the characteristics that the list addresses: personal data, payment transactions, discount and pricing logic, individual permissions and a large number of third-party extensions.
A01, broken access control, is particularly tangible. In a B2B shop with company accounts, sub-users, customer-specific price lists and budget approvals, the authorisation logic decides whether one buyer can see another company's terms. Such errors are difficult to find with automated tools, because the tool does not know the business-level permissions.
A03 is just as practical. Alongside the core, a typical shop brings in dozens of third-party extensions. Each of them is part of the supply chain, and how up to date they are determines the attack surface. A09 also has a direct economic significance: without alerting, an automated log-in attempt with stolen credentials goes unnoticed for weeks.
Real-world example: Log4Shell
The vulnerability CVE-2021-44228 in the widely used Java logging library Apache Log4j, published in December 2021 and known as Log4Shell, shows the supply chain category in its purest form. The applications affected were not those that contained an error but those that included a library that contained an error, often without knowing it, because Log4j came in as a transitive dependency via other components. The decisive question in the days that followed was not a security question in the narrower sense but an inventory question: where in our own portfolio is this library at all? Organisations with a complete inventory of components answered it in hours, others in weeks. It is precisely this experience that lies behind upgrading the supply chain to a separate category, A03.
Practical implementation
The list only realises its value when it is embedded in the development process instead of appearing as a checklist at the end of the project.
- In design: threat modelling for security-critical processes such as log-in, payment, granting permissions and data export.
- In development: static analysis and dependency checking as an automatic step in the pipeline, with a defined failure threshold.
- Before release: dynamic testing of the running application, supplemented by manual tests of the authorisation logic that tools do not cover.
- In operation: logging of security-relevant events with alerting and a rehearsed escalation path.
- Organisationally: a defined process for incoming vulnerability reports and regular refreshing of developers' knowledge.
Limits and common misconceptions
The Top 10 are not a complete list of risks. They name ten categories, not ten vulnerabilities, and deliberately only cover what is broadly relevant. Industry-specific risks are missing. In addition, the data-informed part only reflects what can be tested automatically; OWASP itself points out that the supply chain category in particular is under-represented in the data.
Another misconception concerns the order. The numbering is a ranking by incidence and impact across all applications evaluated, not a prioritisation for a specific system. For an internal tool without user accounts, A01 may be secondary, while A02 dominates.
Outlook
The development over the last two editions points to a shift: classic implementation errors are losing relative weight because frameworks increasingly prevent them on their own. In their place come risks arising from composition and operation: supply chain, configuration, behaviour in exceptional situations. At the same time, European regulation is working in the same direction: the Cyber Resilience Act requires, among other things, a bill of materials of the software components contained in products with digital elements, turning supply chain transparency from a recommendation into an obligation.
Frequently asked questions
How often are the OWASP Top 10 updated?
At intervals of several years, not on a fixed cycle. The 2021 edition was followed by the 2025 edition as the eighth edition.
Are the OWASP Top 10 mandatory?
Not as law. However, they are regarded as the recognised state of the art and are regularly referenced in contracts, security policies and audit requirements; indirectly, this makes them considerably binding.
Is an automated scanner enough for coverage?
No. Tools reliably find what can be recognised without business understanding. Errors in authorisation logic and insecure design require manual testing and threat modelling.
What is the difference between the Top 10 and the ASVS?
The Top 10 are an awareness document with ten risk categories. The ASVS is a verification standard with hundreds of individually testable requirements at graded levels. For acceptance and tenders, the ASVS is the more suitable reference.
Do the Top 10 also apply to interfaces and mobile apps?
Partly. Separate lists exist for these areas, the OWASP API Security Top 10 and the OWASP Mobile Top 10, which target the risks typical there more precisely.
The complete list, including methodology and individual categories, is freely available at owasp.org/Top10.