Web

OWASP Top 10

The OWASP Top 10 (2021) as a checklist: what each category means, why it matters, how to test for it, and which note in this bank goes deep. Some categories are whole notes of their own; others get a brief here so nothing is missed.

The Top 10 is a coverage map, not an attack in itself — work down it so no class of bug goes untested. Where a category has its own deep note, it’s linked; the rest get enough here to test from.

Checklist (2021) — “what did I not test yet”

#CategoryQuick testDeep note
A01Broken Access Controlswap object IDs (IDOR), user token on admin routes, verb tamper, path traversalWeb Attacks · API
A02Cryptographic FailuresHTTP, weak TLS, MD5/SHA1 hashes, secrets in source, guessable tokensCracking
A03InjectionSQLi, command injection, XSS, LDAP/NoSQLSQLi · Cmd · XSS
A04Insecure Designskip workflow steps, replay OTPs, negative quantities, no rate limits
A05Security Misconfigurationdefault creds, verbose errors/stack traces, debug consoles, dir listing, headersRecon & Fuzzing
A06Vulnerable & Outdated Componentsfingerprint versions → map to CVEsServices bank
A07Identification & Auth Failurescredential stuffing, no lockout, weak JWT/session, reset flowLogin Brute · JWT
A08Software & Data Integrity Failuresdeserialization (O:, rO0, ViewState), unsigned updates, CI/CD poisoningSSRF/SS attacks
A09Logging & Monitoring Failures(defensive) are auth-fail/access-deny/input events logged + alerted?
A10SSRFURLs into URL-accepting fields → internal hosts, 169.254.169.254 metadataSSRF

A01 — Broken Access Control

What: users acting outside their intended permissions — IDOR, forced browsing, missing function-level checks (BFLA), path traversal. The most common category in modern apps. Test: change object IDs, swap a user token onto admin endpoints, replay another role’s request. Deep dive: Web Attacks (IDOR / Verb Tampering / BFLA) and API Attacks.

A02 — Cryptographic Failures

What: sensitive data exposed through weak/missing crypto — plaintext transport, weak hashes (MD5/SHA1), hard-coded keys, predictable tokens, srand(time()) seeding. Test: look for HTTP, weak TLS, secrets in source/responses, guessable reset tokens, and crackable password hashes. Cracking lives in the Cracking bank.

A03 — Injection

What: untrusted input interpreted as code/query — SQLi, command injection, LDAP, NoSQL, XSS. Test: see SQL Injection, SQLMap, Command Injection, and XSS.

A04 — Insecure Design

What: flaws baked into the logic, not the code — missing rate limits, broken business workflows, trusting client-side controls, recoverable “secret questions”. Test: abuse the workflow (skip payment steps, replay OTPs, negative quantities), and check that limits exist on sensitive actions.

A05 — Security Misconfiguration

What: default creds, verbose errors, debug consoles, directory listing, missing security headers, unnecessary features enabled. Test: hit default paths/creds, force errors (stack traces leak paths — see the Werkzeug debug PIN), and fuzz for exposed config. Recon: Web Recon & Fuzzing.

A06 — Vulnerable & Outdated Components

What: known-CVE versions of frameworks, libraries and the server stack (the entire Services bank is largely this). Test: fingerprint versions (whatweb, headers, login footers) and map them to CVEs. This is the bridge from web recon into the service-specific notes.

A07 — Identification & Authentication Failures

What: weak login — credential stuffing, no lockout, weak session/JWT handling, predictable reset flows. Test: see Login Brute-Forcing and Broken Authentication & JWT.

A08 — Software & Data Integrity Failures

What: trusting unverified data/updates — insecure deserialization, unsigned updates, CI/CD pipeline poisoning. Test: look for serialized blobs in cookies/params (PHP O:, Java rO0, .NET ViewState), and untrusted plugin/update mechanisms. Deserialization examples appear in Server-Side Attacks and several Services cards (Umbraco, JBoss).

A09 — Security Logging & Monitoring Failures

What: attacks go undetected because nothing is logged/alerted. Mostly a defensive/blue-team gap, but as an attacker it’s why slow brute force and spraying often go unnoticed. Test: (defensive) confirm auth failures, access-control denials and input-validation events are logged and alertable.

A10 — Server-Side Request Forgery (SSRF)

What: the server fetches an attacker-supplied URL — reaching internal services, cloud metadata (169.254.169.254), or local files. Test: see SSRF (and the SSRF-via-URL-field section in API Attacks).

Use this as a pre-engagement checklist: for each app, tick off A01–A10. Anything that maps to a note above has copy-paste payloads there; the brief ones (A04, A05, A09) are mostly logic/config review rather than a single payload.