Introduction to the OWASP Top 10
The OWASP Top 10 is one of the most widely used references for the most critical security risks in web applications. It helps you prioritize what to check first, and how to explain risk clearly to developers and stakeholders.
What is OWASP?
The Open Web Application Security Project (OWASP) is a non-profit foundation that produces:
- The Top 10 (what risks matter most)
- The WSTG (Web Security Testing Guide — how to test)
- Tools like ZAP (Zed Attack Proxy)
The OWASP Top 10 (2021 snapshot)
This list evolves, but the categories are stable enough to structure your work:
| Rank | Category | Short description |
|---|---|---|
| A01 | Broken Access Control | Access to resources you should not have (IDOR, privilege issues) |
| A02 | Cryptographic Failures | Sensitive data exposure due to weak/incorrect crypto |
| A03 | Injection | Untrusted input changes interpretation (SQL, OS commands, LDAP, ...) |
| A04 | Insecure Design | Architectural design flaws and missing security requirements |
| A05 | Security Misconfiguration | Insecure defaults, debug enabled, missing headers, ... |
| A06 | Vulnerable and Outdated Components | Known CVEs in libraries/frameworks |
| A07 | Identification and Authentication Failures | Weak auth/session handling |
| A08 | Software and Data Integrity Failures | Supply chain / build integrity issues |
| A09 | Security Logging and Monitoring Failures | Insufficient telemetry and alerting |
| A10 | Server-Side Request Forgery (SSRF) | Server fetches attacker-controlled URLs into internal networks |
A practical web testing mindset (lab-first)
The goal is not “try random payloads”. The goal is to build a repeatable testing routine:
Step 1 — Map the surface
- endpoints and routes
- inputs (query params, forms, JSON, cookies, headers)
- auth boundaries (public vs authenticated vs admin)
Step 2 — Understand behavior
- status codes and redirects
- sessions, cookies, and CSRF protections
- error handling and logging
Step 3 — Validate risks safely
- reason about the expected control (what should happen)
- send minimal, safe variations in a local lab
- document evidence and remediation
The golden rule: list all input points
| Input point | Examples |
|---|---|
| Query params | `?id=1`, `?page=about`, `?search=test` |
| POST body | Forms, JSON, XML |
| Cookies | `session=...`, `user_id=...`, `role=...` |
| HTTP headers | `User-Agent`, `Referer`, `X-Forwarded-For` |
| Path segments | `/user/123/profile`, `/api/v1/admin` |
Practice environments (recommended)
Use deliberately vulnerable apps in a local lab or official training platforms:
| Lab | Type | Reference |
|---|---|---|
| DVWA | Docker / VM | github.com/digininja/DVWA |
| WebGoat | Docker (OWASP) | owasp.org/WebGoat |
| Juice Shop | Docker (OWASP) | owasp.org/Juice-Shop |
| PortSwigger Academy | Cloud (free) | portswigger.net/web-security |
Flashcards
What is the #1 OWASP Top 10 risk (2021) and why does it matter?
OWASP Top 10 vs WSTG: what’s the difference?
Why should you treat every input point as part of your test surface?
Exercise 1 — Build a simple “app map” (lab-only)
Pick a training target (DVWA / Juice Shop / PortSwigger labs). In a short report, capture:
- 5 important endpoints (login, settings, admin, API, upload)
- the inputs each endpoint accepts (params / body / cookies / headers)
- the auth boundary (public vs authenticated vs admin)
- one “risk hypothesis” per endpoint (what could go wrong?)
Why is mapping (endpoints + inputs) often the most important step of a web test?
Next Lesson
Now that you understand the OWASP Top 10 framework, the next lesson covers Burp Suite—the essential tool for systematic web security testing.
Next: Burp Suite — Essentials