OWASP Top 10
A widely used, regularly updated list of the ten most serious kinds of security flaw found in web applications.
Draft - this entry has not been reviewed yet.
Formal
An awareness document from the open OWASP community that ranks ten broad categories of web application risk, such as broken access control and injection, using data from real tests and a survey of practitioners; it is revised every few years, most recently in 2025.
In plain English
Like a motoring group's list of the ten faults most often found in used cars - not every possible fault, but the ones worth checking first.
In practice
A region buying a new patient portal writes into the tender that the supplier must document testing against every category on the OWASP Top 10 before go-live.
Why it matters
It gives developers, testers and buyers a shared starting point and a common language, but it is a floor rather than a full checklist - covering all ten does not make an application safe.
Technical deep dive
The list first appeared in 2003 and has been revised in 2004, 2007, 2010, 2013, 2017, 2021 and 2025, making the 2025 edition the eighth. Since 2021 it has been built from two inputs. OWASP collects testing data from contributing organisations, maps the findings to CWE identifiers, groups related CWEs into categories and ranks them using incidence in the data together with exploitability and impact scores derived from the CVSS data of the mapped CVEs. Because tool-based data lags behind what practitioners see, eight of the ten categories are chosen from the data and two are promoted from a community survey. For 2025 the data covered more than 2.8 million applications and 589 CWEs, and the ten categories contain 248 CWEs between them.
The 2025 categories are A01 Broken Access Control, 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. Compared with 2021, Server-Side Request Forgery is no longer its own category and has been folded into A01, Vulnerable and Outdated Components has been broadened into supply-chain failures covering compromises anywhere in the ecosystem of dependencies, build systems and distribution, and A10 is new, covering error handling, failing open and unhandled edge cases. XSS has sat inside Injection since 2021 and CSRF was dropped as a separate entry in 2017.
The categories are root causes and weakness families, not individual bugs, so a single finding can plausibly map to several of them, and the ranking says nothing about the risk in a particular application. OWASP describes the document as an awareness document and explicitly points organisations that want a testable standard to the Application Security Verification Standard (ASVS), which defines verification requirements at three levels. Using the Top 10 as an acceptance criterion in contracts or as a scanner "compliance" checkbox is a common misuse, since several categories, notably A06 Insecure Design, cannot be verified by automated testing at all.
Separate lists exist for other technology areas and should not be confused with the main list: the OWASP API Security Top 10 (2023 edition), the Mobile Top 10 and the Top 10 for LLM Applications. PCI DSS and many procurement templates reference the Top 10 or ASVS as examples of industry-accepted secure coding guidance, and the list is likewise often cited in public tenders and supplier contracts.
What to learn first
Everything this builds on, foundations first.
- Network
- →Threat
- →IP address
- →Protocol
- →Vulnerability
- →Client
- →Packet
- →Port
- →Server
- →TCP/IP
- →HTTP
- →Web application
- →OWASP Top 10
Relationships
- Requires
- VulnerabilityWeb application
Sources & further reading
Reference works
- OWASP Top 10:2025 · OWASP
- OWASP Top Ten project · OWASP
- OWASP Top 10:2025 - Introduction (What's new in 2025) · OWASP
Where this data comes from
This entry was drafted by an AI from the sources above and has not yet been checked by a person. Treat it as a starting point, and check anything important against the sources.
See the review queueSuggest a correction on GitHubThis term as JSON
Mentioned in
Check yourself
Loading…