OWASP Top 10

The OWASP Top 10 is the closest thing web security has to an industry standard shortlist of what goes wrong. Published by the Open Worldwide Application Security Project, it aggregates data from hundreds of organizations and thousands of real applications to rank the ten most critical categories of web application risk. It gets updated every few years — the current edition is from 2021, and the rankings shift meaningfully between editions as attack patterns evolve and defenses improve.

What the OWASP Top 10 Is (and Is Not)

The Top 10 is an awareness document. It is not a compliance checklist, not a penetration testing methodology, and not an exhaustive list of every possible vulnerability. Its purpose is to get development teams thinking about the most common classes of security flaws so they can build defenses in from the start. That said, if your application is vulnerable to items on this list, you have company — most of these categories appear in nearly every pentest report.

The Ten Categories

A01: Broken Access Control

Previously #5, now #1. This is when users can act outside their intended permissions — viewing another user's data, escalating to admin, or accessing API endpoints they should not reach. If you read the authentication vs authorization lesson, this is authorization failing.

Example: An API endpoint /api/users/42/profile returns data based solely on the ID in the URL. Change 42 to 43 and you see someone else's profile. This is an Insecure Direct Object Reference (IDOR).

Mitigation: Deny by default. Enforce access control server-side on every request. Never rely on the client hiding a button or URL.

A02: Cryptographic Failures

Formerly "Sensitive Data Exposure." This covers failures in protecting data at rest and in transit — weak encryption, missing TLS, hardcoded keys, storing passwords in plaintext or with weak hashing algorithms like MD5.

Example: A database stores user passwords hashed with unsalted SHA-1. When the database is breached, attackers crack the hashes in hours using rainbow tables.

Mitigation: Use TLS everywhere. Hash passwords with bcrypt, scrypt, or Argon2. Encrypt sensitive data at rest. Never roll your own crypto.

A03: Injection

Code injection happens when untrusted input is sent to an interpreter as part of a command or query. SQL injection is the classic case, but this category also includes NoSQL injection, OS command injection, LDAP injection, and XSS (cross-site scripting). We cover SQL injection and XSS in their own dedicated lessons later.

Example: A login form builds a SQL query by concatenating the username field directly: SELECT * FROM users WHERE name = ' + input. An attacker types ' OR 1=1 -- and bypasses authentication entirely.

Mitigation: Use parameterized queries or prepared statements. Validate and sanitize input. Use an ORM that handles escaping for you.

A04: Insecure Design

This is a newer category that separates design-level flaws from implementation bugs. Insecure design means the application's architecture is fundamentally missing security controls — no rate limiting on authentication, no abuse-case analysis, no separation of trust boundaries.

Example: A password reset flow emails a 4-digit code with no rate limit and no lockout. An attacker brute-forces all 10,000 combinations in minutes.

Mitigation: Threat model during design. Write abuse cases alongside use cases. Establish secure design patterns and reference architectures before writing code.

A05: Security Misconfiguration

Default credentials left in place, unnecessary features enabled, overly permissive CORS, stack traces returned in production error responses, S3 buckets open to the public. This is the "you left the door unlocked" category.

Example: A cloud storage bucket is configured with public read access. Sensitive customer documents are indexed by search engines.

Mitigation: Harden all environments. Automate configuration checks. Remove unused features, frameworks, and endpoints. Review cloud IAM policies.

A06: Vulnerable and Outdated Components

Using libraries, frameworks, or OS components with known vulnerabilities. This is not exotic — it is mundane dependency management. The Log4Shell vulnerability (CVE-2021-44228) is a textbook example: a single logging library compromise affected millions of applications.

Example: An application uses a three-year-old version of a JSON parsing library with a known remote code execution vulnerability. Attackers scan for it at scale.

Mitigation: Keep dependencies updated. Run npm audit, pip audit, or equivalent regularly. Use tools like Dependabot or Snyk. Know what is in your dependency tree.

A07: Identification and Authentication Failures

Weak passwords allowed, credential stuffing not mitigated, session IDs in URLs, missing multi-factor authentication on sensitive accounts. This is the broader category around authentication getting it wrong.

Example: An application permits passwords like "password123" and has no brute-force protection. Attackers use credential stuffing with leaked password databases and compromise thousands of accounts.

Mitigation: Enforce strong password policies. Implement MFA. Use rate limiting and account lockout. Never expose session identifiers in URLs.

A08: Software and Data Integrity Failures

This covers failures to verify that software updates, critical data, or CI/CD pipelines have not been tampered with. It includes insecure deserialization (previously its own Top 10 entry) and supply chain attacks.

Example: An application auto-updates from a CDN without verifying the integrity of the downloaded package. An attacker compromises the CDN and pushes a backdoored version.

Mitigation: Verify digital signatures on updates. Use Subresource Integrity (SRI) for CDN-hosted scripts. Secure your CI/CD pipeline. Review dependencies for unexpected changes.

A09: Security Logging and Monitoring Failures

If you cannot detect a breach, you cannot respond to it. This category covers insufficient logging, logs that do not capture security events, alerts that no one monitors, and incident response plans that do not exist.

Example: An attacker brute-forces admin credentials over several weeks. No failed login attempts are logged, no alerts fire, and the breach is not discovered until customer data appears on a dark web marketplace.

Mitigation: Log authentication events, access control failures, and input validation failures. Monitor logs with alerting. Have and test an incident response plan.

A10: Server-Side Request Forgery (SSRF)

SSRF occurs when an application fetches a remote resource based on a user-supplied URL without validating the destination. Attackers use this to reach internal services, cloud metadata endpoints, or internal APIs that are not exposed to the internet.

Example: An image preview feature accepts a URL parameter. An attacker provides http://169.254.169.254/latest/meta-data/ and retrieves AWS IAM credentials from the instance metadata service.

Mitigation: Validate and sanitize all user-supplied URLs. Use allowlists for permitted domains. Block requests to internal IP ranges and cloud metadata endpoints. Disable unnecessary URL schemes.

How the List Changes

The 2017 edition had "XML External Entities (XXE)" as its own category — by 2021, it was folded into Injection. "Cross-Site Scripting" used to be standalone but is now part of Injection as well. Insecure Design and SSRF were added in 2021. The rankings are data-driven: they reflect what actually shows up in real applications, not theoretical risk.

Which Categories Get Their Own Lessons

Several of these categories are important enough to warrant deep dives in this course. Injection (specifically SQL injection), XSS, and CSRF each get their own dedicated lesson where we walk through attack mechanics, real payloads, and specific defenses.

Key Takeaways

• The OWASP Top 10 is an awareness document based on real-world data, not a compliance checklist — treat it as a starting point for secure development
• Broken Access Control is now #1, reflecting how commonly applications fail to enforce authorization rules on the server side
• Injection (SQL, XSS, command) remains a top risk — parameterized queries and input validation are your primary defenses
• Many categories overlap in practice: a misconfigured server (A05) running outdated components (A06) with no logging (A09) is a single breach waiting to happen
• The list evolves between editions as attack patterns shift — new categories like SSRF and Insecure Design reflect modern cloud and architectural risks
• Most pentest reports will reference multiple Top 10 items; familiarity with all ten saves you from repeating the industry's most common mistakes

Next up: how HTTP stays stateless while servers remember who you are — cookies, sessions, and JWTs.