The OWASP Top 10 — The Map
In one line: The OWASP Top 10 is the security industry's shared, regularly-updated list of the ten most critical categories of web application risk — and it's the map this chapter follows, because if you can recognize and defend these ten, you've covered the overwhelming majority of how real applications get breached.
Imagine a checklist that the whole security profession agrees on: "here are the ten ways web apps most commonly get hacked — make sure none of them apply to yours." That's the OWASP Top 10. OWASP (the Open Worldwide Application Security Project) is a nonprofit that, every few years, studies enormous amounts of real-world vulnerability data and publishes the ten categories of risk that matter most. It's not an exhaustive list of every bug, and it's not a standard you "comply" with — it's a prioritized starting map. Almost every breach you read about maps to one of these ten. This lesson gives you the whole map at a glance; the rest of the chapter zooms into the ones a security engineer must master cold.
What OWASP and the Top 10 are
- OWASP — the Open Worldwide Application Security Project: a vendor-neutral nonprofit that produces free security resources (the Top 10, testing guides, cheat sheets, and tools like ZAP).
- The OWASP Top 10 — a periodically refreshed (roughly every 3–4 years) ranking of the most critical web application security risk categories, built from real vulnerability data contributed across the industry plus a practitioner survey.
Two things it is not, which beginners get wrong:
- It's not a checklist of individual bugs — each entry is a broad category (e.g., "Injection" covers SQL, command, and several other injection types). Defending the category means defending all its members.
- It's not a security standard or certification. "We follow the OWASP Top 10" is a floor, not a guarantee. It's a prioritization aid, not a compliance regime (that's Chapter 10).
- Vulnerability class / category — a family of related weaknesses sharing a root cause and defense (e.g., all injection flaws share "untrusted data interpreted as code").
- CWE (Common Weakness Enumeration) — a detailed catalog of specific weakness types. Each OWASP category maps to a set of CWEs; OWASP groups them into ten human-friendly buckets.
- Risk vs. prevalence vs. severity — OWASP ranks categories by a blend of how common they are, how easy to exploit, and how damaging — i.e., by risk, not by any single factor.
The ten categories (the current map)
The list below reflects the most recent OWASP Top 10. The exact ranking and titles shift between editions — that's expected; treat the categories as durable and the ordering as a dated detail (see the note at the end).
| # | Category | The one-line essence |
|---|---|---|
| A01 | Broken Access Control | Users can act outside their intended permissions — reach others' data, hit admin functions. The most prevalent category. → lesson |
| A02 | Cryptographic Failures | Sensitive data not protected properly — missing encryption, weak algorithms, leaked keys. → Chapter 2 |
| A03 | Injection | Untrusted input is interpreted as a command — SQL, OS commands, and (in this list) XSS. → injection · XSS |
| A04 | Insecure Design | The flaw is in the design itself, not a coding bug — a missing control that should have been threat-modeled in. → Chapter 4 |
| A05 | Security Misconfiguration | Insecure defaults, verbose errors, open cloud storage, unnecessary features left on. |
| A06 | Vulnerable & Outdated Components | Using dependencies with known vulnerabilities — the supply-chain surface. → Chapter 4 |
| A07 | Identification & Authentication Failures | Weak login, broken sessions, credential stuffing, missing MFA. → broken auth |
| A08 | Software & Data Integrity Failures | Trusting code/data without verifying it — unsigned updates, insecure deserialization, CI/CD tampering. → deserialization |
| A09 | Security Logging & Monitoring Failures | You can't detect or respond to what you don't log. → Chapter 6 |
| A10 | Server-Side Request Forgery (SSRF) | The server is tricked into making requests on the attacker's behalf — a pivot into internal systems and cloud metadata. → SSRF |
How the categories cluster (and where this chapter goes deep)
Ten items is a lot to hold at once. They cluster into a few root ideas you already met in Foundations:
- "Untrusted input becomes a command" → Injection (A03), including XSS, plus SSRF (A10) and deserialization (A08). The trust-boundary failures. This chapter's core.
- "The wrong person can do the wrong thing" → Broken Access Control (A01) and Authentication Failures (A07). The identity failures. Also this chapter's core.
- "We protected data badly" → Cryptographic Failures (A02). Covered in Chapter 2.
- "We built or configured it wrong / shipped known-bad parts" → Insecure Design (A04), Misconfiguration (A05), Vulnerable Components (A06). Process and supply chain — Chapter 4.
- "We can't see what's happening" → Logging & Monitoring Failures (A09). Covered in Chapter 6.
This chapter focuses hard on the two bolded clusters — injection-family and identity failures — because they're the application-layer bugs a security engineer finds, exploits (in authorized testing), and fixes most. The other clusters are also in the Top 10, but their deep treatment lives in the chapters noted.
Before the Top 10, every team argued about what "secure enough" meant. A shared, data-driven list gives the whole industry a common language and a sane default priority order: fix access control and injection before you obsess over exotic attacks. When you write a finding, file a ticket, or scope a pentest, referencing the OWASP category instantly tells everyone what you mean and how serious it is.
Why it matters
- It's the prioritization most teams actually use. Limited time? Defend the Top 10 first — by construction, that's where the risk concentrates. It turns "secure the app" (paralysing) into ten concrete, ranked questions.
- It's the shared vocabulary of the field. Pentest reports, bug bounty triage, security tickets, and interviews all speak in OWASP categories. "It's an A01 / broken access control issue" is understood instantly.
- It's the spine of this chapter. Each remaining lesson takes one (or a cluster) of these categories, shows the attack in a traced example, and gives the durable defense.
Common pitfalls
- Treating it as a complete checklist. The Top 10 is the most critical categories, not all risks. Passing a Top-10 review doesn't mean "secure" — business-logic flaws and chapter-specific risks live outside it.
- Memorizing the ranking instead of the root causes. The numbers and order change each edition. What's durable is why each category exists and how you defend it — memorize the defenses, not "A03."
- Reading it as a compliance standard. It's guidance, not a regulation. You don't "certify" against the Top 10; you use it to prioritize. Real compliance frameworks are Chapter 10.
- Stopping at awareness. Knowing the names is step one. The job is recognizing each in real code and shipping the fix — which is what the rest of this chapter trains.
Page checkpoint
Did the OWASP map stick?
Pass to unlock the Next button belowThe specific numbering, titles, and ordering above track the latest OWASP Top 10 edition and will shift in future editions (categories get merged, renamed, or re-ranked as data changes). Treat the categories and their defenses as evergreen and re-check the current edition for the exact list — this is one of the guide's deliberately version-pinned spots.
What's next
→ Continue to Injection — the category that most vividly demonstrates the trust-boundary idea: how a single unescaped input turns your database into the attacker's.
→ Going deeper: the crypto category is Chapter 2; design, misconfiguration, and components are Chapter 4; logging is Chapter 6.