What is the OWASP Top 10
The ten most critical web application security risks, and why every engineer should be able to recite them from memory
TL;DR
A ranked list of the ten most dangerous web application vulnerability classes — think of it as a fire-code checklist: not every possible fire hazard, just the ones that burn buildings down most often.
The idea
The OWASP Top 10 is a consensus document published by the Open Web Application Security Project that names the ten vulnerability categories responsible for the vast majority of real-world web application breaches. It is updated roughly every three to four years based on data contributed by hundreds of organisations. It is not a standard, a test suite, or a certification — it is a prioritised awareness framework that tells engineers where attackers actually go first.
Where it shows up
System-design interviews: Interviewers at security-conscious companies (and increasingly all mid-to-large-sized companies) will ask how you would protect an API or web service. Naming the relevant Top 10 category — "this endpoint is vulnerable to injection if we concatenate user input into a query" — signals you think in threat models, not just features.
On-call / incident response: When a page fires for anomalous database traffic at 2 AM, the Top 10 gives you an immediate triage shortlist. Unexpected UNION SELECT patterns in logs? That's A03 Injection. Sudden lateral movement through a session token? A07 Identification and Authentication Failures. Having the taxonomy internalized speeds root-cause analysis.
Real systems: PCI-DSS, SOC 2, and many enterprise vendor security questionnaires explicitly reference OWASP Top 10 compliance. If your team ships an API consumed by a bank, you will fill out a form asking whether you test against it. Bug bounty programmes frequently map reported vulnerabilities to Top 10 categories as a shared severity vocabulary between researchers and engineering teams.
Read the detailed breakdown›
Where the list comes from
OWASP collects vulnerability data from penetration testing firms, bug bounty platforms, and CVE databases — the 2021 edition drew on data from over 500,000 instances across more than 200 organisations. They count both incidence rate (what fraction of tested applications had this flaw) and weighted severity to produce the final ranking. This matters: the list is empirical, not theoretical. A vulnerability class that is trivially exploitable but rare ranks lower than one that is moderately severe but ubiquitous.
The 2021 list in depth
A01 — Broken Access Control (moved up from #5 in 2017): The most prevalent category in the 2021 data. Applications fail to enforce what authenticated users are allowed to do. Classic patterns: a user changes /account?id=123 to /account?id=124 and sees another user's data (Insecure Direct Object Reference, IDOR); a regular user hits an admin endpoint that lacks a server-side role check; CORS is misconfigured so a cross-origin attacker can make credentialed requests. Access control is hard to automate away — it requires deliberate, per-endpoint authorisation logic.
A02 — Cryptographic Failures (was "Sensitive Data Exposure"): The rename signals a shift from symptom to cause. The real failure is usually in how cryptography is used, not whether it's present. Storing passwords with MD5 or unsalted SHA-1, transmitting secrets over HTTP, using ECB mode for block ciphers, or generating keys with a weak PRNG all fall here. The fix is protocol selection and key management discipline, not just "add TLS".
A03 — Injection: SQL injection is the archetypal case, but the category covers LDAP injection, OS command injection, SSTI (server-side template injection), and more. Injection happens when untrusted data is sent to an interpreter as part of a command or query. Parameterised queries and prepared statements eliminate SQL injection structurally — the interpreter never sees user input as code. Input validation is a defence-in-depth measure, not a primary control.
A04 — Insecure Design (new in 2021): The only category that cannot be fixed by patching — it addresses threat modelling and security requirements gaps baked into the architecture. If a password-reset flow sends a 4-digit numeric PIN by email, no amount of WAF rules will fix it. The fix is design review and abuse-case analysis before code is written.
A05 — Security Misconfiguration: Default credentials, directory listing enabled, verbose error messages that leak stack traces, unnecessary services running, missing security headers (Content-Security-Policy, X-Frame-Options). This is the category most often found by automated scanners and the easiest to catch in CI/CD if you wire in a tool like OWASP ZAP or a header-checking step.
A06 — Vulnerable and Outdated Components: Log4Shell (CVE-2021-44228) is the canonical 2021-era example — a single vulnerable library present in thousands of applications, trivially exploitable via a crafted log message. The control is a software bill of materials (SBOM) and a dependency update pipeline. Tools like Dependabot, Snyk, and OWASP Dependency-Check automate the detection side.
A07 — Identification and Authentication Failures (was "Broken Authentication"): Credential stuffing works because people reuse passwords and applications permit unlimited login attempts. Weak session tokens, missing re-authentication before sensitive operations, and sessions that survive logout all live here. Multi-factor authentication and proper session lifecycle management (token rotation, server-side invalidation) are the primary controls.
A08 — Software and Data Integrity Failures (new in 2021): Covers CI/CD pipeline attacks and insecure deserialisation. If your build pipeline pulls a dependency from a public registry without verifying a checksum or signature, an attacker who poisons that package can ship malicious code through your release process. The SolarWinds supply-chain attack is the reference incident. Controls: signed artefacts, pinned dependencies, pipeline integrity checks.
A09 — Security Logging and Monitoring Failures: Not a vulnerability that enables initial compromise, but the absence of logging is what turns a breach into a catastrophe. If you cannot answer "when did this start, which accounts were affected, what data was accessed" within hours of an incident, this category explains why. SIEM integration, structured log formats, and alerting on authentication anomalies are the baseline.
A10 — Server-Side Request Forgery (SSRF): Added based on community survey data rather than incidence statistics, reflecting its growing severity in cloud environments. An SSRF flaw lets an attacker make the server issue HTTP requests on their behalf — critically, to the cloud metadata endpoint (169.254.169.254 on AWS/GCP/Azure), which can leak IAM credentials. The Capital One breach (2019) involved an SSRF against the EC2 metadata service. Controls: block private IP ranges in outbound request validators, use IMDSv2 (which requires a PUT request an SSRF cannot trivially forge).
How to use the list without misusing it
The Top 10 is a starting point, not a complete security programme. It intentionally omits categories with lower incidence — clickjacking, business logic flaws, race conditions — that can still cause severe breaches in specific applications. Use it to anchor your threat model and to ensure you have at minimum addressed the most statistically common attack surface, then extend with application-specific analysis. Treating the list as a checklist to tick and declare "done" is itself a security antipattern.