OWASP Top 10 Security Risks
OWASP Top 10 Security Risks
Definition: A regularly updated awareness document from the Open Worldwide Application Security Project ranking the most critical web application security risks, based on aggregated real-world vulnerability data.
How It Works
The OWASP Top 10 (most recently revised in 2021, with the next major revision expected periodically) categorizes vulnerabilities by root cause rather than by specific exploit technique, so the list ages more slowly than any single CVE list:
- Broken Access Control: authenticated users can act outside their intended permissions, for example editing another user’s data by changing an ID in a URL.
- Cryptographic Failures: weak or missing encryption for sensitive data at rest or in transit; previously named “Sensitive Data Exposure,” renamed to focus on the root cause rather than the symptom.
- Injection: untrusted input is interpreted as code or commands by an interpreter (SQL, OS shell, LDAP, NoSQL), now including Cross-Site Scripting (XSS), which was previously its own category.
- Insecure Design: missing or inadequate threat modeling and secure design patterns baked in from the start, a category added specifically to push security earlier than implementation-time code review.
- Security Misconfiguration: default credentials, verbose error messages, unnecessary features enabled, or permissive cloud storage (public S3 buckets).
- Vulnerable and Outdated Components: using libraries, frameworks, or dependencies with known CVEs, often unknowingly through transitive dependencies.
- Identification and Authentication Failures: weak session management, credential stuffing exposure, missing MFA, previously named “Broken Authentication.”
- Software and Data Integrity Failures: trusting unsigned or unverified code, updates, or CI/CD pipeline artifacts, a category added after high-profile supply-chain attacks.
- Security Logging and Monitoring Failures: insufficient audit trails, meaning breaches go undetected for longer, extending attacker dwell time.
- Server-Side Request Forgery (SSRF): the server is tricked into making a request to an unintended destination, often an internal service that shouldn’t be reachable from outside.
Under the Hood
The list is built from a combination of survey data (practitioners ranking what they see most) and quantitative data contributed by vendors and bug bounty programs, mapped against CWE (Common Weakness Enumeration) categories. Injection remains dangerous at a technical level because interpreters don’t distinguish code from data unless the application explicitly enforces that boundary. A SQL query built with string concatenation ("SELECT * FROM users WHERE id = " + userInput) fails this boundary. A parameterized query sends the query structure and the user-supplied value to the database separately, so the database engine never treats the value as executable SQL syntax regardless of its content. SSRF works similarly at the network layer: application code fetches a URL on the server’s behalf (an image proxy, a webhook validator), and if that URL isn’t restricted, an attacker points it at internal-only endpoints like a cloud metadata service (169.254.169.254), often extracting credentials the server itself has no business exposing externally.
A typical SSRF exploit sequence: (1) the application exposes a feature that fetches a user-supplied URL server-side, like a “preview this link” or “validate this webhook” feature; (2) the attacker submits an internal-only URL instead of a normal external one, for example http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>; (3) the server, trusting that the URL is just another web resource, makes the request from inside its own trusted network context, where that metadata endpoint is reachable; (4) the response, often containing live temporary cloud credentials for whatever role the server runs as, is returned to the attacker through the same feature, either directly in the response body or inferred through response timing/size if the feature doesn’t echo content back; (5) the attacker uses those credentials directly against the cloud provider’s API, entirely bypassing any network-perimeter controls, since the request now looks like a legitimately authenticated call.
SSRF Attack Mechanics, End to End
The same five steps, drawn as a request flow crossing from an untrusted client into the server’s own trusted network context:
The critical control point is C: an egress allowlist or a network policy that blocks the server from ever reaching link-local metadata addresses closes this entire path in one place, regardless of how many different features in the application fetch user-supplied URLs.
Why It Matters
- Serves as the baseline checklist most security audits, penetration tests, and compliance frameworks (PCI-DSS, SOC 2) reference or require coverage of.
- Reflects what’s actually exploited in practice, not theoretical risk, because it’s derived from real incident and scanning data across thousands of applications.
- Gives non-specialist engineering teams a manageable, prioritized starting point instead of an overwhelming general security literature.
Common Pitfalls
- Trusting any user input, including hidden form fields, cookies, and HTTP headers, without server-side validation and parameterization
- Treating “we passed an OWASP Top 10 scan” as equivalent to being secure, when the list is a floor, not a ceiling, and doesn’t cover business-logic flaws
- Patching the specific reported vulnerability without addressing the systemic root cause, so the same class of bug reappears elsewhere in the codebase
- Ignoring dependency vulnerability scanning (
npm audit,pip-audit, Dependabot) until a critical CVE forces an emergency patch - Assuming SSRF only matters for obviously “URL fetching” features, when it can hide in PDF generators, image processors, and webhook systems
- Relying on blocklisting specific internal IP ranges to stop SSRF instead of allowlisting known-good external destinations, since blocklists miss DNS rebinding, redirect chains, and IPv6/alternate-encoding tricks
- Treating each of the ten categories as independent, when real breaches usually chain two or three together, an SSRF that reaches credentials an over-permissioned IAM role should never have granted
Comparison
| OWASP Top 10 | CWE Top 25 | CVE Database | |
|---|---|---|---|
| Scope | Web application risk categories | Software weakness types, broader than web | Specific, individually disclosed vulnerabilities |
| Update cadence | Every few years | Annual | Continuous |
| Best used for | Prioritizing secure design and review focus | Classifying root causes across all software | Tracking and patching known, specific flaws |
| Granularity | Coarse, categorical | Medium | Fine, per-instance |
| Maintained by | OWASP (volunteer/community) | MITRE | MITRE, with contributions from vendors and researchers |
| Typical consumer | Developers, architects | Tool vendors, static analysis rule authors | Security teams, patch management |
2021 List vs. 2017 List
| 2021 Category | Corresponding 2017 Category | Change |
|---|---|---|
| A01 Broken Access Control | A5 Broken Access Control | Moved up from #5 to #1, most common risk in submitted data |
| A02 Cryptographic Failures | A3 Sensitive Data Exposure | Renamed to target root cause, not just the symptom |
| A03 Injection | A1 Injection, A7 XSS | XSS merged into Injection |
| A04 Insecure Design | New | Added, no prior direct equivalent |
| A05 Security Misconfiguration | A6 Security Misconfiguration | Broadened scope, absorbed some of A4 XXE |
| A06 Vulnerable and Outdated Components | A9 Using Components with Known Vulnerabilities | Renamed, expanded scope |
| A07 Identification and Authentication Failures | A2 Broken Authentication | Renamed, broadened |
| A08 Software and Data Integrity Failures | A8 Insecure Deserialization | Broadened beyond just deserialization to cover CI/CD and update integrity |
| A09 Security Logging and Monitoring Failures | A10 Insufficient Logging & Monitoring | Renamed |
| A10 Server-Side Request Forgery | New | Added, previously not a standalone category |
Example
The 2017 Equifax breach traced back to an unpatched Apache Struts component (Vulnerable and Outdated Components, category 6) combined with insufficient monitoring that let attackers exfiltrate data over months undetected (category 9). Using parameterized statements like SELECT * FROM users WHERE id = ? with the value bound separately prevents SQL injection (category 3) regardless of what a user submits as id. A cloud storage bucket left with public read/write access due to a default configuration is a textbook Security Misconfiguration (category 5).
A concrete Injection example: a login form builds SELECT * FROM users WHERE username = ' + input + ' AND password = '...'. Submitting admin'-- as the username truncates the query after the comment marker, so it evaluates as SELECT * FROM users WHERE username = 'admin', silently dropping the password check entirely and logging the attacker in as admin with no valid credentials at all.
Real-World Case Study
The 2019 Capital One breach is a textbook example of SSRF (category 10): an attacker exploited a server-side request forgery flaw in a misconfigured web application firewall, tricking it into querying the cloud provider’s internal instance metadata service. That service returned live temporary credentials for the IAM role attached to the firewall, which the attacker then used directly against cloud storage to access over 100 million customer records. It’s also a useful illustration of how OWASP categories compound in practice: the root technical flaw was SSRF, but the scale of the damage was determined by a separate failure, an over-permissioned IAM role, showing why the Top 10 categories are best treated as a checklist to audit together rather than one vulnerability class fixing the whole risk on its own.
Related OWASP Projects
- ASVS (Application Security Verification Standard): a detailed, testable checklist that goes far deeper than the Top 10, used to define security requirements for an application.
- Cheat Sheet Series: practical, implementation-level guidance for defending against each risk category, the natural next step after identifying a Top 10 issue.
- Dependency-Check / Dependency-Track: tooling for identifying known-vulnerable dependencies, directly addressing category 6 (Vulnerable and Outdated Components).
- ZAP (Zed Attack Proxy): a free, widely used dynamic application security testing (DAST) tool for finding several Top 10 categories, particularly injection and misconfiguration, in a running application.
- SAMM (Software Assurance Maturity Model): a framework for assessing and improving an organization’s overall secure development practices, addressing category 4 (Insecure Design) at a process level.
History
- 2003: the first OWASP Top 10 was published, focused mainly on injection and input validation issues that dominated early-2000s web application flaws.
- 2010, 2013, 2017: subsequent revisions tracked the industry’s shifting risk landscape, adding categories like broken authentication and XML External Entities (XXE) as those attack classes became prominent.
- 2021: the most recent major revision restructured around root cause rather than symptom, merged XSS into Injection, and added Insecure Design, Software and Data Integrity Failures, and Server-Side Request Forgery as new categories reflecting supply-chain and cloud-era risks.
- Between full revisions, OWASP maintains related projects (ASVS, Cheat Sheet Series, Dependency-Check) that go deeper on implementation guidance than the Top 10’s awareness-level format supports.
FAQ
Is the OWASP Top 10 a checklist that guarantees security if followed? No, it’s a minimum baseline of the most common risk categories, not a complete security program. Business-logic vulnerabilities, for example, often fall outside any of the ten categories entirely.
Why was Cross-Site Scripting folded into Injection in 2021? Because both are fundamentally the same root cause, untrusted input reaching an interpreter (the browser’s HTML/JS parser, in XSS’s case) without proper encoding or sanitization, so OWASP consolidated them under one conceptual category.
Does passing an automated OWASP Top 10 scanner mean an application is secure? No, automated scanners catch a subset of the list, mainly injection and known misconfiguration patterns. Broken Access Control and Insecure Design usually require manual review or testing to catch.
How does SSRF differ from a typical injection flaw? Injection tricks an interpreter into executing attacker data as code; SSRF tricks the server itself into making an unintended network request on the attacker’s behalf, exploiting server-side trust in a URL rather than a language interpreter.
Why is Broken Access Control ranked #1 instead of Injection? The 2021 reordering reflects submitted vulnerability data, not severity alone: access control flaws (viewing or editing another user’s data by changing an ID) appeared in a larger share of tested applications than any other category, even though a single injection bug can be more severe per-incident.