The OWASP Top 10 is embarrassing. Not because it exists — it’s one of the most important documents in application security. It’s embarrassing because the list barely changes. Injection has been on it since 2003. Broken authentication has been on it since 2003. Security misconfiguration has been on it since 2003. The application security community has had two decades of warnings, frameworks, tools, training, conferences, certifications, and regulatory mandates, and the same vulnerability classes keep showing up in production, year after year, breach after breach.

The OWASP Top 10 isn’t a comprehensive vulnerability taxonomy. It’s a consensus document — a data-driven ranking of the most critical web application security risks. If your application is vulnerable to something on this list, you’re in the company of most of the internet. That’s not a comfort.

The TLDR

The OWASP Top 10 (2021 edition) ranks the most critical web application security risks based on real-world vulnerability data from hundreds of organizations and thousands of applications. The categories are: Broken Access Control (A01), Cryptographic Failures (A02), Injection (A03), Insecure Design (A04), Security Misconfiguration (A05), Vulnerable and Outdated Components (A06), Identification and Authentication Failures (A07), Software and Data Integrity Failures (A08), Security Logging and Monitoring Failures (A09), and Server-Side Request Forgery (A10). Each category encompasses dozens of specific CWE (Common Weakness Enumeration) types. Together, they account for the vast majority of web application breaches. If you secure against these ten categories, you’ve addressed the threat landscape that actually matters.

The Reality

These aren’t exotic vulnerabilities exploited by nation-state hackers with custom toolkits. These are the basic, preventable flaws that script kiddies find with automated scanners. The Verizon DBIR consistently attributes the majority of web application breaches to vulnerability exploitation and stolen credentials — both of which trace directly back to OWASP Top 10 categories.

The 2021 edition reorganized the list based on data from over 500,000 applications. Broken Access Control moved to the number one spot. Injection dropped from first to third — not because injection is less common, but because access control failures are even more prevalent. A new category, Insecure Design, was added to highlight the reality that no amount of secure coding can fix a fundamentally insecure architecture.

Every category on this list has a body count. Equifax (vulnerable components). Capital One (SSRF and misconfigurations). SolarWinds (software integrity). Yahoo (cryptographic failures). The breaches are different. The root causes are on this list.

How It Works

A01: Broken Access Control

The number one risk. Access control enforces that people can only access what they’re authorized to access. When it breaks, folks can read other people’s data, modify records they shouldn’t touch, or escalate their privileges to admin.

Real-world example: In 2019, First American Financial exposed 885 million records because their document access system used sequential URLs with no authorization check — change the document ID in the URL, get someone else’s mortgage documents. That’s IDOR (Insecure Direct Object Reference), a subset of broken access control mapped to CWE-639.

Access control must be enforced server-side. Client-side controls (hiding buttons, disabling form fields) are cosmetic — the HTTP request still works. Deny by default. Test every endpoint with unauthorized and differently-authorized accounts.

A02: Cryptographic Failures

Previously “Sensitive Data Exposure,” this category focuses on failures in cryptography that lead to data exposure. Using MD5 or SHA-1 for password hashing. Transmitting data over HTTP instead of HTTPS. Storing encryption keys alongside the encrypted data. Using ECB mode for block ciphers.

Real-world example: The 2013 Adobe breach exposed 153 million passwords encrypted with 3DES in ECB mode without salting — the same password always produced the same ciphertext, making the entire database trivially crackable. CVE-2013-0340 and the related breach demonstrated why cryptographic implementation details matter as much as the algorithm choice.

Use modern algorithms: bcrypt/scrypt/Argon2 for passwords, AES-256-GCM for symmetric encryption, TLS 1.2+ for transport. NIST SP 800-175B provides the authoritative guidance on cryptographic standards.

A03: Injection

Injection happens when untrusted data is sent to an interpreter as part of a command or query. SQL injection, NoSQL injection, OS command injection, LDAP injection, XSS (cross-site scripting) — same principle, different interpreters.

Real-world example: The 2008 Heartland Payment Systems breach — 130 million credit card numbers stolen via SQL injection on a public-facing web application. MITRE ATT&CK T1190 (Exploit Public-Facing Application) documents this attack pattern. In 2023, the MOVEit Transfer SQL injection (CVE-2023-34362) compromised over 2,600 organizations and 77 million individuals.

The fix has been known for decades: parameterized queries, prepared statements, stored procedures, and input validation. ORMs help. Output encoding prevents XSS. The technology to prevent injection exists. The problem is that developers keep writing string concatenation into queries because it’s easier.

A04: Insecure Design

New in 2021, this category recognizes that some vulnerabilities are architectural, not implementation-level. No amount of secure coding can fix a system that was designed without security in mind. Missing rate limiting on authentication. No anti-automation controls on account creation. Business logic that allows negative quantities in a shopping cart.

Real-world example: The 2020 SolarWinds attack exploited, among other things, a design that allowed software updates to execute with full system privileges without integrity verification — a design decision, not a coding bug. The CISA Advisory documents the scope.

Insecure design requires secure design practices: threat modeling, abuse case development, security architecture reviews, and design patterns that enforce security constraints. OWASP’s Cheat Sheet Series provides design-level guidance for common scenarios.

A05: Security Misconfiguration

Default credentials left unchanged. Unnecessary services running. Directory listing enabled. Stack traces in error messages. Cloud storage buckets open to the public. These aren’t code vulnerabilities — they’re operational failures.

Real-world example: The 2017 Accenture breach exposed four AWS S3 buckets containing 137 GB of sensitive data because public access wasn’t disabled. CWE-16 (Configuration) is the root. The 2019 Capital One breach (CVE-2019-5418) involved a misconfigured WAF and overly permissive IAM roles.

Automation is the answer. Configuration management tools (Ansible, Terraform), security benchmarks (CIS Benchmarks), and continuous configuration scanning prevent drift. A hardened baseline that’s enforced by automation beats a hardening checklist that’s forgotten after deployment.

A06: Vulnerable and Outdated Components

Your application is mostly other people’s code. Frameworks, libraries, plugins, runtime environments — if any of them have known vulnerabilities, your application inherits those vulnerabilities. And nobody updates their dependencies.

Real-world example: The Equifax breach (2017) exploited CVE-2017-5638, a vulnerability in Apache Struts that had been patched two months before the breach. 147 million people’s data, compromised because a known-vulnerable library wasn’t updated. Log4Shell (CVE-2021-44228) in 2021 was even more devastating — a critical RCE in a logging library used by millions of Java applications.

Know what you’re running. Software Composition Analysis (SCA) tools — OWASP Dependency-Check, Snyk, Dependabot — scan your dependency tree against known CVE databases. Automate dependency updates. Remove unused dependencies. Subscribe to security advisories for your critical components.

A07: Identification and Authentication Failures

Weak password policies, credential stuffing without rate limiting, session tokens in URLs, missing MFA, insecure password recovery — all the ways authentication breaks down.

Real-world example: The 2012 Dropbox breach resulted from an employee reusing a password across services. When LinkedIn was breached, that password gave attackers access to a Dropbox employee’s account, which contained a file with customer email addresses. MITRE ATT&CK T1110 (Brute Force) and T1078 (Valid Accounts) document these attack patterns.

Enforce MFA. Implement rate limiting and account lockout. Use established session management frameworks. Check passwords against breach databases (the Have I Been Pwned API is free). NIST SP 800-63B provides modern authentication guidance that finally retired complexity requirements in favor of length and breach checking.

A08: Software and Data Integrity Failures

This category covers code and infrastructure that doesn’t verify integrity. Insecure CI/CD pipelines, auto-updates without signature verification, deserialization of untrusted data, and dependency confusion attacks all fall here.

Real-world example: The SolarWinds Orion attack injected malicious code into the build pipeline, so legitimate software updates delivered backdoors to 18,000 organizations. The Codecov breach (2021) modified a bash uploader script to exfiltrate CI/CD environment variables — including credentials and tokens — from every organization that used it.

Sign your code. Verify signatures before execution. Use lock files and integrity hashes for dependencies. Secure your build pipeline as aggressively as your production environment — because it is a production environment. SLSA (Supply-chain Levels for Software Artifacts) provides a framework for supply chain integrity.

A09: Security Logging and Monitoring Failures

If you can’t see the attack, you can’t stop it. Insufficient logging, logs that aren’t monitored, and incident response processes that don’t exist mean breaches go undetected for months.

Real-world example: The 2013 Target breach went undetected for weeks despite FireEye alerts flagging the malware. The alerts were generated — and ignored. The breach was eventually detected by the US Department of Justice, not by Target’s own security team. The IBM Cost of a Data Breach Report consistently shows that breaches detected internally cost significantly less than those reported by third parties.

Log security-relevant events: authentication successes and failures, authorization failures, input validation failures, admin actions, and data access patterns. Centralize logs. Monitor them. Set up alerts. Test your incident response process. NIST SP 800-92 and OWASP Logging Cheat Sheet provide the guidance.

A10: Server-Side Request Forgery (SSRF)

SSRF occurs when a web application fetches a remote resource based on a user-supplied URL without validating it. The attacker makes the server send requests to internal resources — metadata services, internal APIs, file systems — that should never be reachable from the outside.

Real-world example: The 2019 Capital One breach used SSRF to access the AWS EC2 metadata service at 169.254.169.254, which returned IAM role credentials. Those credentials gave access to S3 buckets containing 100 million customer records. CVE-2019-5418 and MITRE ATT&CK T1552.005 (Cloud Instance Metadata API) document this pattern.

Validate and sanitize all URLs. Block requests to internal IP ranges (RFC 1918, link-local, loopback). Use allowlists instead of denylists. In cloud environments, enforce IMDSv2 (AWS) or equivalent protections that require session tokens for metadata access.

How It Gets Exploited

Automated scanning. Tools like Nuclei, SQLMap, and custom scripts scan the entire internet for OWASP Top 10 vulnerabilities. Your unpatched Struts instance, your public S3 bucket, your login page without rate limiting — they’ll be found within hours of exposure.

Chaining vulnerabilities. Attackers rarely exploit a single vulnerability. They chain them. An SSRF gives access to internal metadata. The metadata provides credentials. The credentials access a database with broken access control. Each vulnerability is “medium severity” individually. Together, they’re a breach.

Targeting known CVEs. When a CVE is published for a popular framework, mass exploitation begins within days. CISA’s Known Exploited Vulnerabilities Catalog tracks the vulnerabilities actively being exploited in the wild. If your dependencies are on this list and unpatched, it’s not a question of if — it’s when.

What You Can Do

Learn the list. Every developer who writes web applications should be able to describe all ten categories and the secure coding practices that prevent them. OWASP’s Cheat Sheet Series provides actionable, language-specific guidance for each one.

Test for them. Add SAST and DAST to your CI/CD pipeline. SAST catches injection patterns, hardcoded secrets, and insecure cryptographic usage in code. DAST tests the running application for access control failures, misconfigurations, and SSRF. OWASP ZAP is free and automatable.

Update your dependencies. Enable automated dependency updates. Run SCA tools. Subscribe to the security advisories for every framework and library in your stack. When a critical CVE drops, you should know within hours and have a patch timeline in days — not months.

Model your threats. The OWASP Top 10 tells you what’s common. Threat modeling tells you what’s relevant to your specific application. Use STRIDE or PASTA to identify where your application is most vulnerable, then prioritize your defenses accordingly.

Related Deep Dives

Sources & Further Reading