OWASP Top 10

The OWASP Top 10 is the industry's reference list of the most critical web application security risks, published by the Open Worldwide Application Security Project and periodically updated from analysis of hundreds of thousands of real applications. It's the shared vocabulary of application security: penetration test reports, compliance questionnaires, and security training all organize themselves around it.

It's a risk awareness document, not a checklist — "we covered the Top 10" doesn't make an app secure. But as a map of where web applications actually bleed, it's the right first lens: the same handful of mistake categories account for the vast majority of real-world breaches.

TL;DR

The Ten Risks

Based on the OWASP Top 10 (2021 edition — the current published list, with a new revision long in progress):

A01 — Broken Access Control

Users acting outside their permissions: reading others' records by changing an ID, calling admin endpoints without the role, modifying someone else's data.

Defend: deny by default; check ownership/role on the server for every request; never rely on hiding buttons. This category alone justifies code-review attention — see API Security.

A02 — Cryptographic Failures

Sensitive data exposed through absent or broken cryptography: plaintext or weakly hashed passwords (MD5/SHA-1), missing TLS, hardcoded keys, home-rolled crypto.

Defend: TLS everywhere; passwords with bcrypt/argon2 (Password Security); vetted libraries and managed KMS for encryption at rest; classify data so you know what needs protecting.

A03 — Injection

Untrusted input interpreted as code by an interpreter — SQL, NoSQL, OS commands, LDAP, and (per OWASP's grouping) XSS.

Defend: parameterized queries/ORMs, never string-built commands; context-aware output encoding (framework templates do this); allowlist validation at the boundary. Details: SQL Injection, XSS.

A04 — Insecure Design

Flaws in the design itself, which no perfect implementation can fix: password recovery via guessable security questions, business logic that trusts client-side price fields, missing rate limits on money-moving endpoints.

Defend: threat model features before building ("how would I abuse this?"); establish secure design patterns; abuse-case tests alongside use-case tests.

A05 — Security Misconfiguration

Default credentials, directory listings, verbose stack traces in production, permissive CORS, unnecessary features enabled, missing security headers, cloud storage buckets set public.

Defend: hardened, repeatable configuration via infrastructure as code; minimal platform (remove what you don't use); automated config scanning; separate error detail for logs vs clients.

A06 — Vulnerable and Outdated Components

Running libraries, frameworks, and runtimes with known CVEs — the Log4Shell/Equifax category. Modern apps are mostly dependencies; their vulnerabilities are your vulnerabilities.

Defend: dependency scanning in CI (Dependabot, npm audit, Snyk, Trivy); an update cadence, not update-on-breach; inventory (SBOM) so you know what you run; prune unused packages.

A07 — Identification and Authentication Failures

Weak login mechanics: credential stuffing unimpeded, missing MFA, predictable session tokens, sessions that survive logout, exposed session IDs in URLs.

Defend: rate-limit and monitor login; MFA (phishing-resistant for admins — WebAuthn); framework session management with rotation on login; see Authentication.

A08 — Software and Data Integrity Failures

Trusting updates, plugins, or serialized data without verification: compromised CI pipelines, unsigned auto-updates, insecure deserialization, malicious packages in the supply chain.

Defend: verify signatures on updates/artifacts; lock and review dependency changes; treat the CI/CD pipeline as production infrastructure (it deploys code — it is an attack path); avoid deserializing untrusted data.

A09 — Security Logging and Monitoring Failures

Breaches discovered months late because nothing recorded the attack: no auth-failure logs, no alerting on anomalies, logs that vanish or are never reviewed.

Defend: log auth events, access-control denials, and input validation failures with user/IP context (Logging); centralize (Log Aggregation); alert on patterns (spray attempts, mass enumeration); test that incident response actually fires.

A10 — Server-Side Request Forgery (SSRF)

The app fetches a URL an attacker controls, from inside your network — reaching internal services and cloud metadata endpoints:

Defend: allowlist fetchable hosts/schemes; block private IP ranges and metadata addresses (after DNS resolution — beware rebinding); enforce IMDSv2 on AWS; egress-restrict the fetching service at the network layer.

Using the Top 10 Well

Common Mistakes

Treating It as a Compliance Checklist

"Top 10 covered" on a slide has preceded many breaches. The list names risk categories — each expands into dozens of concrete requirements (that's ASVS's job).

Buying Tools for People Problems

Scanners find outdated dependencies and missing headers; they don't find "any user can read any invoice." The top risk category (A01) is precisely the one only humans reviewing authorization logic catch.

Securing the App, Ignoring the Pipeline

A08 is the modern blind spot: an attacker in your CI system ships whatever they like, with your signatures. Pipeline credentials, runner isolation, and dependency provenance deserve production-grade scrutiny.

Logging Everything Except What Matters (or Too Much of What Doesn't)

Terabytes of debug logs with no auth-failure trail fails A09 twice — you can't detect the attack, and you may be storing sensitive data (tokens, PII) that becomes its own exposure.

FAQ

Is the Top 10 updated often?

Roughly every 3–4 years (2013, 2017, 2021, with the next revision in progress). Categories shift and merge — e.g., XSS folded into Injection, SSRF added — but the core themes (access control, injection, misconfiguration) persist across every edition.

Where should a small team start?

Three moves cover a disproportionate share: (1) authorization checks on every endpoint against the resource owner, (2) parameterized queries + framework templating everywhere, (3) dependency scanning in CI. Then add MFA and security headers — an afternoon each.

How do I test my app against the Top 10?

Layered: automated scanners (ZAP, Burp) and dependency/config scanning for the mechanical categories; code review focused on authorization; periodic penetration testing for the logic flaws automation misses. OWASP's Juice Shop is the standard practice target.

Does using a modern framework handle this for me?

Partially — Rails/Django/Spring-era frameworks parameterize queries, escape templates, and manage sessions correctly by default, which is why injection declined. Frameworks cannot know your authorization rules, your design flaws, or your dependency hygiene: A01, A04, A06 remain fully yours.

Top 10 vs ASVS vs Cheat Sheets?

Top 10 = awareness (what goes wrong). ASVS = verification standard (what to require, per assurance level). Cheat Sheet Series = implementation guidance (how to do each control right). Use them in that order.

Related Topics

References