OWASP Top Ten Vulnerabilities Explained
The OWASP Top Ten is the most widely referenced classification of critical web application security risks, published by the Open Web Application Security Foundation (OWASP) and used as a baseline by regulatory frameworks, procurement requirements, and enterprise security programs across the United States and internationally. This page covers the structure, mechanics, classification logic, and regulatory context of the Top Ten list, with attention to how individual categories are defined, how they interrelate, and where practitioners, auditors, and security researchers encounter definitional ambiguity. The list informs compliance obligations under frameworks including PCI DSS, NIST, and FedRAMP, making it operationally relevant beyond its role as an awareness document.
- Definition and Scope
- Core Mechanics or Structure
- Causal Relationships or Drivers
- Classification Boundaries
- Tradeoffs and Tensions
- Common Misconceptions
- Checklist or Steps
- Reference Table or Matrix
Definition and Scope
The OWASP Top Ten is a ranked enumeration of the ten most critical security risk categories affecting web applications, updated periodically by the Open Web Application Security Foundation based on data gathered from application security firms, bug bounty programs, and vulnerability disclosures. The 2021 edition — the most operationally active release as of the list's publication cycle — is the version cited in PCI DSS v4.0 (PCI Security Standards Council), NIST guidance documents, and procurement language in federal acquisition contexts.
The scope of the Top Ten is explicitly risk-oriented, not vulnerability-oriented. OWASP distinguishes between a vulnerability (a specific flaw in code or configuration) and a risk category (a class of weaknesses with shared exploitability, prevalence, and impact characteristics). Each of the ten entries aggregates multiple Common Weakness Enumeration (CWE) identifiers from MITRE's CWE catalog (MITRE CWE). The 2021 list maps across 40+ CWEs, compared to fewer than 30 in the 2017 edition, reflecting a shift toward broader categorical framing.
The Top Ten explicitly does not cover every significant vulnerability class. It focuses on web application contexts and does not encompass mobile-specific risks (addressed in OWASP's separate Mobile Application Security Verification Standard), API-specific risks (addressed in the OWASP API Security Top 10), or infrastructure-layer risks. Understanding this scope boundary is essential for organizations using the list as a compliance anchor.
Core Mechanics or Structure
Each entry in the 2021 Top Ten is structured around five data dimensions: mapped CWEs, maximum incidence rate, average incidence rate, average CVSSv3 score, and total CVEs mapped. This quantified structure differentiates the 2021 edition from earlier versions, which relied more heavily on expert consensus and less on aggregated data.
The 2021 list consists of:
- A01: Broken Access Control — moved from position 5 in 2017 to the top position; found in 94% of applications tested in the OWASP data set. See Broken Access Control Risks for enforcement-layer detail.
- A02: Cryptographic Failures — renamed from "Sensitive Data Exposure" to reflect the root cause rather than the symptom; maps to CWEs including CWE-259, CWE-327, and CWE-331.
- A03: Injection — formerly the top-ranked category; now consolidated to include SQL injection, OS command injection, LDAP injection, and related variants. Coverage of injection attack prevention addresses mitigation controls.
- A04: Insecure Design — a new category in 2021 addressing architectural and design-level flaws rather than implementation errors; references threat modeling as a primary preventive discipline. Threat modeling for applications describes that practice in detail.
- A05: Security Misconfiguration — broadened from earlier versions to absorb the former "XML External Entities (XXE)" category; covers cloud, container, and framework-level misconfiguration.
- A06: Vulnerable and Outdated Components — formerly "Using Components with Known Vulnerabilities"; directly implicates software composition analysis and third-party dependency management.
- A07: Identification and Authentication Failures — renamed from "Broken Authentication"; maps to 22 CWEs including CWE-287 and CWE-384.
- A08: Software and Data Integrity Failures — new in 2021; incorporates deserialization vulnerabilities (formerly A08 in 2017) and insecure CI/CD pipeline assumptions.
- A09: Security Logging and Monitoring Failures — previously "Insufficient Logging and Monitoring"; identified through penetration testing and breach post-mortems rather than static data.
- A10: Server-Side Request Forgery (SSRF) — added in 2021 based on community survey data despite relatively low incidence rates, reflecting high severity when exploited in cloud environments.
Causal Relationships or Drivers
The Top Ten's composition is driven by three observable forces: exploitation frequency reported in breach data, industry survey input from security practitioners, and the maturation of tooling that makes certain vulnerability classes more reliably detectable.
Broken Access Control rose to first position because authorization logic defects are structurally difficult to detect with automated scanning — static application security testing tools flag approximately 19% of access control issues in OWASP's contributing dataset, while manual review and dynamic application security testing account for the remainder. The gap between automated detection rates and actual prevalence produces persistent underreporting in organizations that rely solely on SAST pipelines.
Cryptographic Failures (A02) are driven by legacy protocol adoption — applications using TLS 1.0 or 1.1, MD5, or SHA-1 remain common in enterprise contexts. The National Institute of Standards and Technology deprecated SHA-1 for most uses through NIST SP 800-131A Rev 2 (NIST SP 800-131A), yet implementation lag persists across long-lived applications.
Insecure Design (A04) entered the list as a structural response to the observation that vulnerability remediation at code level is insufficient when the underlying architecture lacks security controls by design. OWASP cites threat modeling, secure design patterns, and reference architectures as the primary countermeasures, reflecting influence from the NIST Secure Software Development Framework (SSDF) (NIST SP 800-218).
Classification Boundaries
The Top Ten uses risk categories, not individual vulnerabilities. This creates classification overlap that practitioners must navigate precisely.
Cross-Site Scripting (XSS) appeared as a standalone category (A07) in the 2017 list but was absorbed into A03: Injection in 2021. Organizationally, cross-site scripting (XSS) remains a distinct vulnerability type with its own CWE identifiers (CWE-79, CWE-80, CWE-83) and requires separate remediation logic from SQL injection, even though both fall under A03.
Similarly, cross-site request forgery (CSRF) does not appear as a standalone category in either the 2017 or 2021 editions, despite being a significant web application attack vector. CSRF is implicitly captured under A07: Identification and Authentication Failures via session management weaknesses, but the Top Ten does not explicitly enumerate it.
Deserialization vulnerabilities shifted from a standalone entry (A08 in 2017) to a sub-component of A08: Software and Data Integrity Failures in 2021. This reclassification reflects OWASP's intent to group root causes (integrity assumption failures) rather than symptoms.
Organizations building control frameworks directly from the Top Ten must account for these boundary shifts when mapping between the 2017 and 2021 editions, particularly in compliance contexts where audit criteria may reference specific year editions.
Tradeoffs and Tensions
The Top Ten's risk-category framing creates genuine tension with vulnerability management workflows that operate at the CVE or CWE level. A penetration test finding of SQL injection maps to A03, but so does OS command injection, LDAP injection, and template injection — four distinct technical problems with different remediation paths. Aggregation into a single category assists executive communication but reduces precision for engineering teams.
The addition of Insecure Design (A04) is contested among practitioners. Critics argue it is too broad to drive actionable remediation and that it conflates architecture review (a pre-development discipline) with code-level controls (a development-phase discipline). Proponents cite its value in shifting security investment upstream, aligning with DevSecOps principles in secure software development lifecycle methodologies.
The inclusion of SSRF (A10) despite low average incidence rates — lower than several excluded vulnerability classes — illustrates the tension between statistical prevalence and severity-weighted community judgment. OWASP explicitly acknowledged this tradeoff in the 2021 edition notes, treating SSRF as forward-looking given the expansion of cloud metadata endpoint exposure in AWS, Azure, and GCP environments.
Logging and Monitoring Failures (A09) cannot be detected by conventional application security scanners. Its presence in the Top Ten reflects a philosophical position that detection capability is a security control, not merely an operational function. This categorization is contested by practitioners who argue the Top Ten should restrict itself to exploitable technical vulnerabilities.
Common Misconceptions
The Top Ten is not a comprehensive vulnerability standard. It covers 10 risk categories aggregating roughly 40 CWEs. MITRE's CWE catalog contains over 900 distinct weakness types. Using the Top Ten as a complete security checklist leaves substantial attack surface unaddressed.
Passing a Top Ten assessment does not imply PCI DSS compliance. PCI DSS v4.0 Requirement 6.2.4 references OWASP Top Ten as a training and awareness benchmark, not as a substitute for the full requirement set. The PCI Security Standards Council (PCI SSC) is explicit that application security requirements extend beyond OWASP Top Ten coverage.
The 2017 and 2021 editions are not interchangeable. Three categories are entirely new in 2021 (Insecure Design, Software and Data Integrity Failures, SSRF), and three categories from 2017 were absorbed or merged. Audit criteria, training programs, and tooling configured against the 2017 list require revision.
Automated scanning does not reliably cover the entire Top Ten. A01 (Broken Access Control), A04 (Insecure Design), and A09 (Logging and Monitoring Failures) have particularly low automated detection rates. Web application security testing programs require human-driven assessment components to address these categories.
OWASP Top Ten is not a regulatory mandate by itself. It becomes regulatory-relevant when explicitly incorporated by a framework — as in PCI DSS v4.0 — but standing alone it is a community-produced reference document, not a legal requirement.
Checklist or Steps
The following sequence reflects a structured implementation review against OWASP Top Ten categories, as used in application security assessments. This is a reference enumeration, not prescriptive professional advice.
Phase 1: Scope and Edition Alignment
- Confirm which edition (2017 or 2021) applies to the relevant compliance context
- Map existing vulnerability findings to the correct edition's CWE groupings
- Identify categories excluded from automated scanning scope (A01, A04, A09)
Phase 2: Tooling Coverage Assessment
- Verify SAST tooling CWE coverage against A02, A03, A05, A06, A07, A08
- Confirm DAST tooling coverage for A01, A03, A07, A10
- Identify gaps requiring manual review or interactive application security testing
- Validate software composition analysis tooling against A06 (Vulnerable Components)
Phase 3: Category-Specific Control Review
- A01 Broken Access Control: Review role/permission matrices, test privilege escalation paths
- A02 Cryptographic Failures: Audit protocol versions, key lengths, and hashing algorithms against NIST SP 800-131A
- A03 Injection: Validate parameterized query usage; test all input vectors
- A04 Insecure Design: Review threat model documentation; validate security requirements coverage
- A05 Security Misconfiguration: Audit cloud, container, and framework default configurations
- A06 Vulnerable Components: Generate and review SBOM against known CVE databases
- A07 Authentication Failures: Test MFA enforcement, session timeout, and credential policies
- A08 Integrity Failures: Validate CI/CD pipeline integrity controls and deserialization handling
- A09 Logging Failures: Verify log coverage for authentication events, access control decisions, and input validation failures
- A10 SSRF: Test all server-side URL fetch operations; review cloud metadata endpoint access controls
Phase 4: Findings Documentation and Tracking
- Map each finding to specific CWEs within the applicable Top Ten category
- Record detection method (automated, manual, penetration test)
- Track remediation status against category-level closure criteria
Reference Table or Matrix
| Top Ten Category (2021) | 2017 Position | Primary CWEs | Primary Detection Method | Automated Tool Coverage |
|---|---|---|---|---|
| A01: Broken Access Control | A05 | CWE-22, CWE-285, CWE-639 | Manual / DAST | Low |
| A02: Cryptographic Failures | A03 (Sensitive Data Exposure) | CWE-259, CWE-327, CWE-331 | SAST / Manual | Moderate |
| A03: Injection | A01 | CWE-79, CWE-89, CWE-78 | SAST / DAST | High |
| A04: Insecure Design | New in 2021 | CWE-209, CWE-256, CWE-501 | Manual / Threat Model | Very Low |
| A05: Security Misconfiguration | A06 (+ XXE from A04) | CWE-16, CWE-611 | DAST / Config Scan | Moderate |
| A06: Vulnerable Components | A09 | CWE-1104 | SCA | High |
| A07: Authentication Failures | A02 (Broken Auth) | CWE-287, CWE-384 | DAST / Manual | Moderate |
| A08: Software/Data Integrity | A08 (Insecure Deserialization) | CWE-494, CWE-829 | SAST / Manual | Low |
| A09: Logging/Monitoring Failures | A10 | CWE-117, CWE-223, CWE-778 | Manual / Pen Test | Very Low |
| A10: SSRF | New in 2021 | CWE-918 | DAST / Manual | Moderate |
| Regulatory Framework | OWASP Top Ten Reference | Edition Cited | Requirement Context |
|---|---|---|---|
| PCI DSS v4.0 | Requirement 6.2.4 | 2021 (implied) | Developer training mandate |
| NIST SP 800-218 (SSDF) | PW.1.1 task | Not edition-specific | Secure design and code review |
| FedRAMP | AC-1 through AC-6 controls | Not edition-specific | Access control alignment |
| OWASP ASVS 4.0 | Direct chapter mapping | 2021 aligned | Verification standard |
References
- OWASP Top Ten 2021
- OWASP CWE Mapping — 2021 Top Ten
- MITRE Common Weakness Enumeration (CWE)
- NIST SP 800-131A Rev 2 — Transitioning the Use of Cryptographic Algorithms and Key Lengths
- [N