OWASP Top 10 Study Portal

How it works

The list is assembled from contributed application-testing datasets (hundreds of thousands of apps) plus an industry survey for forward-looking risks. Eight of the ten categories are data-driven; two are chosen from the community survey to capture risks that tooling underreports. Categories are intentionally broad "buckets" of related CWEs (Common Weakness Enumerations) rather than single bugs, so each maps to many concrete weaknesses. The ranking factors in average exploitability and impact weights, not just raw frequency. Below is each 2021 category with what it is, a concrete example, and its primary defenses.

A01: Broken Access Control

• What it is: Users can act outside their intended permissions — viewing, modifying, or deleting data or functions they should not reach. Includes IDOR (insecure direct object references), missing function-level checks, privilege escalation, and CORS misconfiguration. Now ranked #1.
• Real-world example: An API endpoint GET /api/accounts/1024/statements returns any account's statements if you change the ID, because the server trusts the ID in the URL and never checks it belongs to the authenticated user.
• Primary defenses:
• Deny by default; enforce access control server-side in trusted code, never in the client/UI.
• Use a single, central authorization mechanism and reuse it everywhere.
• Enforce ownership on every object access (record-level / row-level checks), not just "is logged in".
• Disable directory listing, rate-limit APIs, invalidate sessions server-side on logout, log access-control failures.

A02: Cryptographic Failures

• What it is: Previously "Sensitive Data Exposure." Failures in (or absence of) cryptography that expose sensitive data — weak/old algorithms, hardcoded or default keys, missing encryption in transit or at rest, improper certificate validation.
• Real-world example: Passwords stored as unsalted MD5 hashes, or PII transmitted over plain HTTP, so a single database dump or network sniff exposes credentials and personal data.
• Primary defenses:
• Classify data; encrypt sensitive data at rest and enforce TLS in transit (HSTS, no downgrade).
• Hash passwords with a memory-hard, salted KDF (Argon2id, scrypt, or bcrypt) — never fast general-purpose hashes.
• Use authenticated encryption (e.g. AES-GCM), strong key management, and disable legacy protocols/ciphers.
• Never hardcode keys; rotate keys and use a secrets manager.

A03: Injection

• What it is: Untrusted input is interpreted as code or commands by an interpreter — SQL, NoSQL, OS command, LDAP, ORM, and (now folded in) Cross-Site Scripting (XSS).
• Real-world example: "SELECT * FROM users WHERE name = '" + input + "'" lets an attacker submit ' OR '1'='1 to dump the table, or '; DROP TABLE users;-- to destroy it.
• Primary defenses:
• Use parameterized queries / prepared statements or a safe ORM — never string concatenation.
• Context-aware output encoding for XSS, plus a strict Content-Security-Policy.
• Server-side allow-list input validation; escape special characters for the specific interpreter.

-- Safe: parameterized query (placeholder, not concatenation)
SELECT * FROM users WHERE name = @name;

Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'; script-src 'self'

A04: Insecure Design

• What it is: A new 2021 category focused on missing or ineffective control design — flaws that exist before a single line is written. You cannot patch your way out of a bad design; this is about threat modeling and secure design patterns, distinct from insecure implementation.
• Real-world example: A "forgot password" flow whose security questions ("mother's maiden name") are publicly discoverable — the feature is correctly coded but fundamentally weak by design.
• Primary defenses:
• Threat model early; establish a secure development lifecycle and reference secure design patterns.
• Use OWASP Proactive Controls and ASVS; build abuse-case and misuse-case tests.
• Segregate tiers, enforce business-logic limits (e.g. plausibility/rate limits per user).

A05: Security Misconfiguration

• What it is: Insecure default configs, incomplete setups, verbose error messages, unnecessary features enabled, missing hardening, or unpatched config. Absorbed the former "XML External Entities (XXE)" category.
• Real-world example: A cloud storage bucket left world-readable, a default admin/admin account left enabled, or stack traces returned to users revealing framework versions and file paths.
• Primary defenses:
• Hardened, repeatable configuration baselines applied via automation across all environments.
• Remove unused features, ports, accounts, and sample apps; disable verbose errors in production.
• Send security headers; review cloud permissions; patch configuration and disable XXE (no DTD processing).

A06: Vulnerable and Outdated Components

• What it is: Running components (libraries, frameworks, runtimes) with known vulnerabilities, or not knowing what versions you run. A supply-chain-adjacent risk that is hard to test dynamically.
• Real-world example: An app pinned to a years-old Log4j or Struts version with a published RCE CVE that an attacker exploits with an off-the-shelf payload.
• Primary defenses:
• Maintain an inventory / SBOM of all components and their versions.
• Use Software Composition Analysis (SCA) in CI; patch promptly; remove unused dependencies.
• Only pull from trusted sources with integrity verification; monitor CVE feeds.

A07: Identification and Authentication Failures

• What it is: Previously "Broken Authentication." Weaknesses in confirming identity and managing sessions — credential stuffing, weak passwords, missing MFA, predictable or non-rotated session IDs, exposed session tokens.
• Real-world example: No rate limiting or lockout on login, so attackers run credential-stuffing lists from prior breaches and take over accounts at scale.
• Primary defenses:
• Implement MFA; block known-breached and weak passwords; rate-limit and add lockout/backoff.
• Use a vetted session manager: high-entropy, server-side session IDs; rotate on login; invalidate on logout/timeout.
• Do not ship default credentials; harden recovery flows.

A08: Software and Data Integrity Failures

• What it is: New in 2021. Code and infrastructure that fail to protect against integrity violations — unsigned/unverified updates, untrusted deserialization, and insecure CI/CD pipelines. Absorbed the former "Insecure Deserialization."
• Real-world example: An auto-update mechanism that downloads and runs updates without verifying a digital signature, letting an attacker push malicious code (a SolarWinds-style supply-chain compromise).
• Primary defenses:
• Verify digital signatures on software, libraries, and updates; pin dependencies with integrity hashes (lockfiles, subresource integrity).
• Harden the CI/CD pipeline; enforce code review and segregation of duties.
• Avoid deserializing untrusted data; if unavoidable, use integrity checks and type allow-lists.

A09: Security Logging and Monitoring Failures

• What it is: Insufficient logging, monitoring, alerting, or incident response — so breaches go undetected. Hard to test but high impact: the difference between a contained incident and a months-long undetected breach.
• Real-world example: Failed logins, access-control denials, and high-value transactions are not logged or alerted, so an ongoing attack runs for months before anyone notices.
• Primary defenses:
• Log auth events, access-control failures, and high-value actions with sufficient context and correlatable IDs.
• Centralize logs, protect their integrity, and ensure they don't leak sensitive data.
• Define alerting thresholds and a tested incident response / escalation plan.

A10: Server-Side Request Forgery (SSRF)

• What it is: New in 2021 (community survey). The server is tricked into making requests to an attacker-chosen destination, often reaching internal services, cloud metadata endpoints, or otherwise unreachable hosts.
• Real-world example: A URL-fetch feature (image/webhook importer) is given http://169.254.169.254/latest/meta-data/iam/..., and the server returns cloud credentials from the instance metadata service.
• Primary defenses:
• Allow-list destination hosts/schemes/ports; deny by default. Block requests to private/link-local/loopback ranges.
• Don't send raw responses back to clients; disable HTTP redirects on server-side fetches.
• Use network segmentation and enforce IMDSv2 (token-bound metadata) in cloud environments.