This module is engineered to be brief by design. You do not need comprehensive mastery over each vector yet — your immediate goal is to calibrate the topographical map before venturing deep into active territory. Chapters 7 through 11 dismantle the highest-yield categories line-by-line.
You'll also walk out knowing how to think like an attacker before you ever touch Burp — that's what "threat modeling" in the title means, and it's a separate skill from memorizing a list.
OWASP doesn't invent this list from opinion. Every few years (most recently 2021, with a 2025 release in progress) the foundation pulls vulnerability data from dozens of partner organizations and AppSec tooling vendors, covering hundreds of thousands of real applications, then maps the findings against CWE (Common Weakness Enumeration) categories. The ranking blends two signals: how often a weakness shows up in the wild, and how severe it tends to be when it does. That's why "Broken Access Control" sits at #1 — not because it's the flashiest bug, but because it's both common and consistently damaging.
Bug bounty triage frameworks — Bugcrowd's VRT and HackerOne's severity guidance among them — lean heavily on this same taxonomy when assigning payout tiers, which is exactly why this list matters to your wallet and not just your résumé.
One thing the OWASP rank does not tell you: what any single bug is worth in a specific program. A misconfigured S3 bucket (A05) leaking customer PII can outpay a textbook IDOR (A01) if the impact is bigger. Category tells you where to look first. Impact + exploitability + program scope is what actually sets the bounty. Treat the table below as a prevalence map, not a price tag.
Filter the framework vectors to highlight where hunters spend most of their time:
| Rank | Security Category | Core Operational Meaning | Hunter Relevance |
|---|---|---|---|
| A01 | Broken Access Control | System fails to validate permissions. Covers IDOR and vertical/horizontal privilege escalation. | Highest |
| A02 | Cryptographic Failures | Weak encryption protocols, cleartext storage, or fragile hashing algorithms. | Medium |
| A03 | Injection | Untrusted input parsed as code or commands by the backend (SQLi, command injection, XSS's core mechanism). | Highest |
| A04 | Insecure Design | Flawed architecture or business logic baked in before a single line of code was written. | Medium |
| A05 | Security Misconfiguration | Default credentials, verbose debug errors, open ports, or exposed admin/asset panels. | High |
| A06 | Vulnerable & Outdated Components | Running unpatched third-party packages or libraries with active, documented CVEs. | High |
| A07 | Identification & Auth Failures | Weak verification flows, session token hijacking, or broken account-recovery logic. | High |
| A08 | Software & Data Integrity Failures | Trusting unsigned updates or unsafely deserializing attacker-controlled data. | Lower |
| A09 | Security Logging & Monitoring Failures | Insufficient audit trails let malicious activity persist undetected. | Rarely Bountied |
| A10 | Server-Side Request Forgery (SSRF) | Tricking a backend server into issuing outbound requests on your behalf — often reaching internal-only systems. | Highest |
Look at the triage breakdown again. Broken Access Control, Injection, Auth Failures, and SSRF sit at the top of hunter relevance. That's not a coincidence — these four defect families produce the overwhelming majority of critical-severity, easily-verified bugs a hunter finds in their first year. They're also exactly the categories Chapters 7 through 11 are built around.
Logging gaps and supply-chain integrity issues are real institutional risks — the kind a security team genuinely worries about — but they rarely produce a clean, independently provable exploit chain for someone hunting solo. Spend your early energy on input handling and authorization boundaries; that's where the proof-of-concept is fastest to build and the report is easiest to validate.
Before you fuzz a single parameter, professional testers ask four questions about a system. This is a stripped-down version of Microsoft's STRIDE model — you don't need to memorize the acronym, but the questions behind it will become second nature by the time you reach Chapter 12 (Recon Methodology).
Forged tokens, predictable session IDs, missing signature checks. Feeds directly into Chapter 3 (JWTs) and Chapter 10 (auth bugs).
Editing hidden fields, price parameters, or request bodies the client never expected a user to alter.
Maps to A09 — weak logging means an action can't be proven to have happened, which matters more to blue teams than bounty hunters.
Verbose errors, exposed debug endpoints, IDOR responses leaking other users' records.
Rarely in scope for bounty programs, but still part of how a real threat model gets built.
The end-state of most A01 chains — start as a normal user, end as someone with more power than they granted you.
In practice, your day-to-day threat modeling will be much simpler than the full STRIDE checklist: every time you see an input field, a URL parameter, or an API call, ask "what trust boundary does this cross, and did the server actually check who's asking?" That single question, repeated relentlessly, is most of what separates a hunter who finds bugs from one who just clicks around.
This module is the map. Here's exactly where you'll get hands-on with each high-priority category:
Can you explain in one sentence what Broken Access Control means in a production environment?
What's the one mechanical difference between an Injection bug and a logic/business-rule bug?
Looking at Figure 5.1 — name one point in a typical login flow where a trust boundary is crossed, and what check should happen exactly there.
Click a high-value vulnerability category on the left, then select its matching exploitation concept on the right: