OWASP Top 10
The OWASP Top 10 ranks the most critical web application security risks from real-world data. Learn what each category means, how findings map to CWE entries, and how to turn the list into acceptance criteria and defense-in-depth controls.
What is this?
The OWASP Top 10 is a regularly refreshed awareness document ranking the most critical web application security risks, derived from data contributed by security firms and breach reports. It is not a certification standard or a compliance checklist — it is a starting point for prioritizing defenses. Each risk entry includes example attack scenarios, prevention guidance and links to canonical CWE weaknesses.
Why do you need it?
- It is the most widely cited starting point for web application security programs.
- It maps directly to Common Weakness Enumeration (CWE) identifiers, so findings can be traced to a canonical weakness.
- It gives teams and stakeholders a shared vocabulary — 'we are not exposed to A01' is instantly understood.
- It focuses on the risks that real breach and engagement data shows are most common and most damaging.
- Each entry ships with concrete prevention guidance you can turn into acceptance criteria and CI gates.
Mental model
A seasonal weather risk forecast
The OWASP Top 10
You do not cancel the harvest because a storm is possible; you learn which risks are most likely this season and strengthen the roof first. The Top 10 tells you which software risks are historically most common so you spend scarce security effort where it pays.
How it works
- OWASP gathers data from participating security organizations about vulnerabilities found in real engagements and publicly documented breaches.
- Risks are ranked across exploitability, prevalence, detectability and impact, not just the severity of a single bug.
- Each entry links to CWE identifiers, example attack scenarios and prevention requirements.
- Organizations map their own findings to the Top 10 to measure exposure and guide training, tooling and design reviews.
- The list is revised on a cycle (2017, 2021, 2025) as the threat landscape, frameworks and tooling evolve.
From OWASP data to an actionable defense plan.
Key commands
curl -sI https://staging.example.com/ | grep -iE "content-security|x-frame|strict-transport|x-content-type"Verify which hardening headers are actually present on responses.
curl -s -o /dev/null -w "%{http_code}" https://staging.example.com/adminEducational check: an unauthenticated request to an admin route should return 401/403.
401
curl -s -o /dev/null -w "%{http_code}" -H "Cookie: <user-session>" https://staging.example.com/admin/consoleProbe function-level access control: a non-admin session must not reach admin functions.
grep -rnE "router\.(get|post|put|delete|patch)" src/routesInventory every route handler so you can spot which ones lack an authorization guard.
curl -sI https://staging.example.com/ | grep -iE "^server:|^x-powered-by:"Check whether the server leaks framework and version details (A05 information disclosure).
Examples
Defending A05: security misconfiguration with hardened headers
// A05 (2021) / A5 (2017) Security Misconfiguration.// Missing or weak headers are the easiest finding to verify and fix.app.use((req, res, next) => { res.setHeader("X-Content-Type-Options", "nosniff") res.setHeader("X-Frame-Options", "DENY") res.setHeader("Referrer-Policy", "strict-origin-when-cross-origin") res.setHeader( "Content-Security-Policy", "default-src 'self'; script-src 'self'; object-src 'none'" ) res.setHeader("Strict-Transport-Security", "max-age=31536000; includeSubDomains") next()})This middleware applies a baseline of protective headers to every response, covering several Top 10 categories at once: X-Frame-Options and the CSP block clickjacking and content injection (A05), HSTS forces HTTPS (A02), and nosniff prevents MIME confusion. These headers are cheap to deploy, easy to assert in tests, and instantly verifiable with a curl header dump.
In production
- Security headers and authorization guards are asserted in CI so regressions fail the build.
- Findings are classified against the Top 10 in the backlog, giving leadership a monthly exposure view.
- Design reviews use the Top 10 as a checklist when new features cross trust boundaries.
- Annual reviews re-map findings to the latest Top 10 refresh to see how the risk profile changed.
Best practices
- Treat the Top 10 as a prioritization aid, not a complete security program.
- Map every security finding to its CWE so it is comparable across teams and tools.
- Turn Top 10 categories into acceptance criteria for new features (e.g., 'no unsafe headers, owner checks required').
- Apply defense-in-depth: no single control (headers, WAF, validation) is ever trusted alone.
- Revisit the list on each refresh and check which new categories apply to your stack.
Common mistakes
- Treating the Top 10 as a certification or a 'pass all ten' compliance box.
- Ignoring categories A01-to-A03 because the app 'uses a framework' — frameworks still leak data and logic.
- Fixing only the categories the current tooling reports and skipping the rest.
- Not mapping findings to CWE, making cross-tool correlation and remediation tracking impossible.
Common issues
HSTS header missing only on the first requestHSTS is emitted after a redirect or only over HTTPS.
Apply the header on every response in the middleware chain and confirm the request actually uses HTTPS.
Admin route returns 200 for a plain userThe route is registered without the authorization guard middleware.
Find the route in the inventory (grep router.*(get|post|...) and attach the guard, then re-run the probe.
CSP header present but a scanner still flags XSSThe CSP uses unsafe-inline or unsafe-eval, which weakens script-source protection.
Review script-src and object-src directives; remove unsafe-inline where the app can avoid inline scripts.
Debugging tips
- Check response headers on every environment (dev, staging, prod) — misconfigurations often differ per deploy.
- Reproduce access-control findings as two separate users to confirm it is a logic flaw, not a data error.
- Cross-reference a scanner finding's CWE ID against the Top 10 category page to confirm the impact framing.
Interview checkpoint
Hands-on lab
- Map WebGoat lessons to their Top 10 categories
- Verify security headers and configuration on the sandbox
- Demonstrate an injection and an access-control lesson
- Tag findings with CWE identifiers and propose a defense
OWASP Top 10 Hunt in WebGoat
40 min · intermediate
Quick quiz
Which OWASP Top 10 category is 'Broken Access Control' under the 2021 refresh?
The OWASP Top 10 is a certification standard you must 'pass'.
Your scanner reports a finding with CWE-79 in the comment section. Which Top 10 category does this map to?
Cheat sheet
A01 Broken Access ControlIDOR, missing function-level checksA02 Cryptographic FailuresWeak hashing, plaintext secretsA03 InjectionSQL, NoSQL, XSS (CWE-79/89)A05 Security MisconfigurationHeaders, defaults, verbose errorsA07 Identification/Auth FailuresSession, brute force, weak credsCWE-639 / CWE-79 / CWE-89Canonical IDs to tag findings