Web Security Cheatsheet
OWASP Top 10
Use this Web Security reference while you build software engineering projects, review code, or refresh the syntax you reach for most.
The current list, OWASP Top 10:2025
The Top 10 is a risk awareness list, not a checklist and not a standard. It orders categories by prevalence in contributed test data plus a community survey. The 2025 edition is the 8th installment.
| ID | Category | Change from 2021 |
|---|---|---|
| A01:2025 | Broken Access Control | Still #1, SSRF folded in |
| A02:2025 | Security Misconfiguration | Up from #5 |
| A03:2025 | Software Supply Chain Failures | New, expands "Vulnerable and Outdated Components" |
| A04:2025 | Cryptographic Failures | Down from #2 |
| A05:2025 | Injection | Down from #3 |
| A06:2025 | Insecure Design | Down from #4 |
| A07:2025 | Authentication Failures | Same rank, renamed |
| A08:2025 | Software or Data Integrity Failures | Same rank |
| A09:2025 | Security Logging and Alerting Failures | Same rank, renamed |
| A10:2025 | Mishandling of Exceptional Conditions | New |
Two additions, two renames, one consolidation. The theme of the 2025 revision is root cause over symptom, which is why supply chain and misconfiguration climbed while specific bug classes slid down.
The 2021 list, still referenced everywhere
Compliance documents, scanner output, and most training material are keyed to the 2021 edition. Know both, because you will be asked to map findings between them.
| ID | Category | Maps to in 2025 |
|---|---|---|
| A01:2021 | Broken Access Control | A01 |
| A02:2021 | Cryptographic Failures | A04 |
| A03:2021 | Injection | A05 |
| A04:2021 | Insecure Design | A06 |
| A05:2021 | Security Misconfiguration | A02 |
| A06:2021 | Vulnerable and Outdated Components | A03 |
| A07:2021 | Identification and Authentication Failures | A07 |
| A08:2021 | Software and Data Integrity Failures | A08 |
| A09:2021 | Security Logging and Monitoring Failures | A09 |
| A10:2021 | Server-Side Request Forgery (SSRF) | A01 |
XSS lives inside Injection in both editions. It is not its own category, which surprises people who learned the 2013 or 2017 lists.
What each category actually means
| Category | The failure, in one line |
|---|---|
| Broken Access Control | The server does not verify that this user may do this action on this object |
| Security Misconfiguration | Defaults left on: debug pages, open buckets, verbose errors, missing headers |
| Software Supply Chain Failures | A dependency, build step, or distribution channel you trusted was compromised |
| Cryptographic Failures | Sensitive data in transit or at rest without adequate protection |
| Injection | Untrusted input reaches an interpreter as code rather than data |
| Insecure Design | The threat was never modeled, so no amount of clean code fixes it |
| Authentication Failures | Weak credentials, weak recovery, broken session lifecycle |
| Software or Data Integrity Failures | Unverified updates, unsigned artifacts, unsafe deserialization |
| Logging and Alerting Failures | The breach happened and nobody was paged |
| Mishandling of Exceptional Conditions | Error and edge-case paths skip the checks the happy path enforces |
Two rules that cover most of it
Almost every category above reduces to one of two mistakes, and they are worth internalizing before any specific technique.
1. Never trust the client. Anything the browser sends is attacker
controllable: form fields, query strings, headers, cookies, hidden inputs,
Origin, Referer, JWT claims you did not verify, and the price in the cart.
Client-side validation is a UX feature. The server decides.
2. Keep data out of the code path. Injection of every flavor is one bug:
untrusted text was concatenated into something that gets interpreted. SQL,
shell, HTML, LDAP, XPath, template engines, and log files all have the same
shape and the same class of fix, which is a parameterized or context-aware API.
Defense in depth
No single control is sufficient. Layer them so one bypass is not a breach.
| Layer | Examples |
|---|---|
| Design | Threat modeling, least privilege, blast-radius limits |
| Input | Type and range validation, canonicalize before validating |
| Interpreter boundary | Parameterized queries, execve-style argv, safe templating |
| Output | Context-aware encoding, Content-Type correctness |
| Transport | TLS 1.2 or better, HSTS, secure cookie attributes |
| Browser | CSP, frame-ancestors, Trusted Types, SRI |
| Identity | MFA, short sessions, rotate on privilege change |
| Runtime | Egress allowlists, resource quotas, least-privilege service accounts |
| Detect | Structured audit logs on authz decisions, alerting on anomalies |
| Recover | Tested backups, documented rotation, an incident runbook |
How to use this reference
Each topic that follows covers one class in the same shape: what the vulnerability is, a minimal illustrative example of the flaw, the concrete fix, and what to look for during code review. There are no exploit recipes here. The goal is that you recognize the pattern in a diff and know the correct replacement.
Primary sources worth bookmarking:
- OWASP Top 10:2025 for the risk categories. - OWASP Cheat Sheet Series for per-topic defensive guidance, which is the deepest free resource on this subject. - OWASP ASVS when you need verifiable requirements rather than awareness. - MDN HTTP headers for exact header and directive syntax.