The OWASP Top 10 is the closest thing the web security industry has to a canonical vulnerability classification. First published in 2003 and updated periodically, the list reflects the most critical security risks to web applications as assessed by a global community of security professionals. The 2021 edition — the current authoritative version — reflects significant changes in how modern applications are built and attacked.
For enterprise security teams, the OWASP Top 10 serves three purposes: it provides a common vocabulary for communicating risk to non-technical stakeholders, it establishes a baseline for security testing requirements, and it informs architecture decisions. PCI DSS v4.0 Requirement 6.2.4 specifically requires that web-facing applications be tested against OWASP Top 10 vulnerabilities. Understanding the list is not optional for security professionals in regulated industries.
The OWASP Top 10 2021: Category by Category
A01: Broken Access Control
Broken access control moved to the top position in 2021, up from fifth in 2017. It represents the most widespread category of web application vulnerability. Access control enforces policy such that users cannot act outside their intended permissions. When these controls fail, attackers can view unauthorized data, modify data that belongs to other users, or perform privileged actions without authorization.
Real-world example: A financial services application displays account balances at /api/accounts/{account_id}. The application verifies the user is authenticated but fails to verify that the authenticated user owns the account identified by account_id. An attacker who knows their own account ID can enumerate adjacent account IDs and view any account's balance. This is an IDOR (Insecure Direct Object Reference) — the most common subclass of broken access control.
Automated scanners detect obvious IDOR in GET parameters. They cannot detect IDOR in POST bodies, IDOR that requires multi-step interaction, or access control failures that depend on understanding the application's authorization model.
A02: Cryptographic Failures
Formerly "Sensitive Data Exposure," this category was renamed to focus on the root cause: cryptographic failures that expose sensitive data. This includes transmitting data in cleartext (HTTP instead of HTTPS, unencrypted database connections), using weak or deprecated algorithms (MD5, SHA-1 for password hashing, DES, RC4), improper key management (hardcoded keys, inadequate key rotation), and failure to encrypt sensitive data at rest.
Real-world example: An internal application stores passwords using unsalted MD5 hashes. Because MD5 is a fast, unsalted-by-design hash, a single modern GPU can compute on the order of hundreds of billions of MD5 guesses per second — so if an attacker exfiltrates a database of MD5-hashed passwords, off-the-shelf tools like hashcat with common wordlists recover the weakest and most common passwords almost immediately. This is why OWASP A02:2021 Cryptographic Failures flags fast hash functions (MD5, SHA-1) as unsuitable for passwords and calls for slow, salted algorithms such as bcrypt, scrypt, PBKDF2, or Argon2. The recovered plaintext passwords are then tested against the organization's Office 365 tenant.
A03: Injection
SQL injection, command injection, LDAP injection, and their variants. Injection vulnerabilities occur when untrusted data is sent to an interpreter as part of a command or query. The interpreter cannot distinguish between intended commands and attacker-supplied data.
Despite being one of the oldest vulnerability classes, injection remains widespread. Second-order SQL injection (described in the penetration testing post) and time-based blind SQL injection — where no error is returned but the application behaves differently based on query truth values — consistently evade automated scanners. Manual testing is required to reliably detect these variants.
A04: Insecure Design
New in 2021, insecure design refers to missing or ineffective security controls at the design level — vulnerabilities that arise from architectural decisions rather than implementation errors. This category is the hardest to detect with any automated tool because it requires understanding what the application is supposed to do and identifying where the design fails to account for adversarial use.
Real-world example: A multi-factor authentication flow allows users to bypass MFA by navigating directly to the post-authentication landing page URL. The application checks authentication state on the login form but not on protected pages, because the designer assumed users would always arrive through the login form. This is an insecure design — there is no CVE entry for it, no scanner signature for it, and no patch that fixes it without redesigning the authentication flow.
A05: Security Misconfiguration
The most commonly found category in practice. Security misconfiguration encompasses: default credentials on administrative interfaces, unnecessary services and ports exposed, verbose error messages revealing stack traces and internal paths, missing security headers (Content-Security-Policy, X-Frame-Options, Strict-Transport-Security), cloud storage buckets with public read access, and unpatched software in production.
A06: Vulnerable and Outdated Components
Applications are built on dependencies — libraries, frameworks, runtimes — and those dependencies have vulnerabilities. The Log4Shell vulnerability (CVE-2021-44228) demonstrated at scale what happens when a ubiquitous library contains a critical remote code execution vulnerability: organizations that could not enumerate their Log4j dependencies could not assess their exposure. Software composition analysis (SCA) tooling is essential for maintaining dependency visibility.
A07: Identification and Authentication Failures
Formerly "Broken Authentication." This category covers weak password policies, credential stuffing susceptibility (no rate limiting on login endpoints), session management failures (predictable session tokens, sessions that survive logout, missing session timeout), and improper MFA implementation. A common finding in web application assessments is login endpoints with no rate limiting — allowing automated credential stuffing attacks against any user account with a breached password.
A08: Software and Data Integrity Failures
New in 2021, this category encompasses CI/CD pipeline integrity failures, insecure deserialization, and code integrity failures — including the SolarWinds-style supply chain attack where malicious code is introduced into a trusted software update mechanism. Insecure deserialization, where attacker-controlled serialized objects are processed by the application, can lead to remote code execution in languages including Java, PHP, and Python.
A09: Security Logging and Monitoring Failures
The absence of adequate logging and monitoring does not cause an initial compromise — but it dramatically extends attacker dwell time and limits incident response effectiveness. OWASP includes this because organizations that cannot detect attacks in progress cannot contain them. The median attacker dwell time before detection remains measured in weeks, not hours, for organizations without mature monitoring capabilities.
A10: Server-Side Request Forgery (SSRF)
SSRF vulnerabilities allow attackers to induce the server-side application to make HTTP requests to an arbitrary domain. In cloud environments, this is particularly dangerous: cloud instance metadata services (AWS IMDSv1, GCP metadata server) are accessible from the server and return IAM credentials. An SSRF vulnerability that reaches the metadata service can result in complete cloud environment compromise via credential theft.
What Enterprise Teams Should Prioritize in 2025
A01 (Broken Access Control) and A04 (Insecure Design) deserve priority attention in 2025. Access control failures are the most commonly exploited category in real-world attacks, and insecure design vulnerabilities are the most frequently overlooked in security programs because they do not appear in any automated scan output.
The practical implication: your web application security testing program must include qualified manual testing against A01 and A04 specifically. No automated tool can reliably detect authorization model failures or architectural security gaps. These require an experienced tester who understands both the application's intended behavior and the adversarial techniques used to subvert it.
A06 (Vulnerable Components) is best addressed with automated SCA tooling integrated into your CI/CD pipeline — this is the one category where automation genuinely excels. A09 (Logging Failures) requires a SIEM and detection engineering investment, not a penetration test.