The OWASP Top 10 is a regularly updated awareness document that ranks the ten most critical security risk categories for web applications, published by the OWASP Foundation (the Open Worldwide Application Security Project). Each entry is a broad category of weaknesses, grouped from many CWE identifiers, rather than a single vulnerability, and the list is combined from contributed testing data and a practitioner survey.
In application security, the OWASP Top 10 serves as a shared vocabulary between developers, testers, auditors and management. It sets the minimum baseline for secure coding training, security testing scope and vendor questionnaires, but it was never designed as a complete standard or a certification target.
How the OWASP Top 10 is compiled
The list is rebuilt every three to four years from two inputs: vulnerability data contributed by testing firms, bug bounty platforms and organizations, and a community survey of practitioners. Editions appeared in 2003, 2004, 2007, 2010, 2013, 2017, 2021 and 2025.
Since 2021, eight categories are selected from data and two from the survey, which lets emerging risks enter before testing tools detect them at scale. Ranking emphasizes incidence rate, the share of tested applications with at least one weakness from the category, adjusted by exploitability and impact scores. Categories are defined by root cause rather than symptom, which is why names such as “Cryptographic Failures” replaced older labels such as “Sensitive Data Exposure”.
The ten risk categories in the 2025 edition
The 2025 edition keeps Broken Access Control at the top, adds supply chain and error-handling categories and folds server-side request forgery into access control. The table summarizes each category with a representative weakness.
| Rank | Category | Core problem | Typical example |
|---|---|---|---|
| A01 | Broken Access Control | Users act outside their permissions | Changing an ID in a URL to read another account |
| A02 | Security Misconfiguration | Insecure defaults and settings | Debug mode or default credentials in production |
| A03 | Software Supply Chain Failures | Compromised or unmanaged dependencies and build systems | Malicious package pulled into a build |
| A04 | Cryptographic Failures | Weak, missing or misused cryptography | Passwords stored with a fast unsalted hash |
| A05 | Injection | Untrusted input interpreted as code or commands | SQL injection or cross-site scripting |
| A06 | Insecure Design | Missing security controls at design level | No rate limit on a password reset flow |
| A07 | Authentication Failures | Weak identity verification and sessions | Credential stuffing without MFA or lockout |
| A08 | Software or Data Integrity Failures | Unverified code, updates or serialized data | Unsigned update or unsafe deserialization |
| A09 | Security Logging and Alerting Failures | Attacks are not recorded or noticed | No alert on mass failed logins |
| A10 | Mishandling of Exceptional Conditions | Unsafe behavior on errors and edge cases | Failing open when an authorization service times out |
Several neighboring concepts map into these categories. XSS and SQL injection belong to Injection, CSRF is classified under Broken Access Control, a CSP is a defense-in-depth control against injected scripts, and an SBOM is a core tool for managing Software Supply Chain Failures.
What changed between 2021 and 2025
Comparing editions shows how attacker focus and data collection have shifted. The 2021 edition introduced Insecure Design and integrity failures; the 2025 edition broadens component risk into the whole supply chain and adds a category for exceptional conditions.
| Category in 2021 | Position in 2025 | Nature of the change |
|---|---|---|
| Broken Access Control (A01) | A01 | Kept at the top; now also covers SSRF |
| Security Misconfiguration (A05) | A02 | Moved up as configuration complexity grew |
| Vulnerable and Outdated Components (A06) | A03 as Software Supply Chain Failures | Expanded to build pipelines and distribution |
| Cryptographic Failures (A02) | A04 | Moved down, scope unchanged |
| Injection (A03) | A05 | Moved down, still includes XSS |
| Server-Side Request Forgery (A10) | Merged into A01 | No longer a separate category |
| Security Logging and Monitoring Failures (A09) | A09, renamed | Emphasis shifted from monitoring to alerting |
| Not present | A10 Mishandling of Exceptional Conditions | New category for error handling and failing open |
A drop in rank does not mean a risk became less dangerous. Injection fell mainly because frameworks with parameterized queries and auto-escaping templates reduced its incidence, while a single injection flaw remains as damaging as before.
OWASP Top 10 compared with related standards
The OWASP Top 10 is an awareness tool, and mature programs pair it with documents built for verification or for other attack surfaces. The comparison below shows where each one fits.
| Reference | Nature | Granularity | Best used for |
|---|---|---|---|
| OWASP Top 10 | Awareness list | 10 broad risk categories | Training, prioritization, shared language |
| OWASP ASVS | Verification standard | Hundreds of testable requirements in three levels | Security requirements and audits |
| OWASP API Security Top 10 | Awareness list for APIs | 10 API-specific risks | REST and GraphQL services |
| OWASP Top 10 for LLM Applications | Awareness list for AI systems | 10 risks such as prompt injection | Applications built on language models |
| CWE Top 25 | Ranked weakness list | 25 specific CWE entries | Tool tuning and code-level focus |
When a contract or policy needs verifiable security requirements, the ASVS is the appropriate reference, because each of its requirements can be tested and marked as passed or failed, while a Top 10 category cannot.
Using the OWASP Top 10 in a development program
The list delivers most value when it is mapped to concrete activities across the software development lifecycle rather than treated as a one-time checklist.
| Lifecycle stage | How the list is used | Limit to keep in mind |
|---|---|---|
| Design and threat modeling | Prompts questions about access, integrity and failure modes | Does not replace a system-specific threat model |
| Developer training | Structures secure coding curricula | Must be paired with framework-specific guidance |
| Static and dynamic testing | Groups SAST and DAST findings by category | Tools detect design flaws poorly |
| Penetration testing | Defines minimum test coverage | Business logic flaws need manual testing |
| Procurement and audits | Gives vendors a common checklist language | Category coverage is not proof of security |
Metrics based on the list, such as open findings per category, help leadership see whether access control or supply chain hygiene is improving over time.
Misconceptions and limitations
The most common errors come from treating the list as something it does not claim to be:
- It is not a standard. There is no such thing as “OWASP Top 10 compliance” or certification; claims of full coverage are marketing.
- It is not exhaustive. Business logic abuse, race conditions and many API or mobile risks fall outside or between its categories.
- Rank is not severity. A lower-ranked category can still contain the most critical flaw in a specific application.
- Scanners cannot cover it. Insecure Design and access control flaws require human review because tools lack knowledge of intended behavior.
- Old editions persist. Many policies still cite 2017 or 2021 categories, so mappings must name the edition explicitly.
In plain words
The OWASP Top 10 is a short list of the most common ways websites and web apps get broken into. Security experts update it every few years based on what they actually find when testing real applications.
Think of it as the list of the ten most frequent causes of house burglaries: unlocked back doors, weak locks, spare keys under the mat. Knowing the list does not make a house safe, but ignoring it almost guarantees trouble. Developers use it to learn what to avoid, and testers use it to decide what to check first.
A real-world example
An online retailer with a team of twelve developers adopts the OWASP Top 10 as the baseline for its security program. Every developer completes training organized by the ten categories, the CI pipeline tags SAST and dependency findings with the matching category, and an annual penetration test must cover all ten as a minimum.
During the first test, the testers notice that invoice URLs contain sequential order numbers. Changing the number in the address returns other customers’ invoices with names and delivery addresses, a textbook A01 Broken Access Control flaw known as an insecure direct object reference. No automated scanner had reported it, because the scanner had no way to know that one customer should not see another customer’s orders.
The team adds a server-side ownership check to every order lookup and writes an automated test for it. The fix took one day, and the category-based reporting later showed leadership that access control findings fell from five to zero over the following two test cycles.