Security Testing
Intermediate 18 min read Security Testing

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.

OWASPTop 10CWEriskbroken access controlinjectionsecurity misconfiguration
Introduction

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.

Motivation

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.
Think about it

Mental model

Imagine

A seasonal weather risk forecast

Think of

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.

Mechanics

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.

Contributed breach data
Risk ranking
Top 10 published
Map your findings
Prioritize defenses
Reference

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/admin

Educational 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/console

Probe function-level access control: a non-admin session must not reach admin functions.

grep -rnE "router\.(get|post|put|delete|patch)" src/routes

Inventory 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).

Hands-on

Examples

Defending A05: security misconfiguration with hardened headers

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.

Real world

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.
Guidelines

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.
Watch out

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.
Root cause analysis

Common issues

Error
HSTS header missing only on the first request
Root cause

HSTS is emitted after a redirect or only over HTTPS.

Fix

Apply the header on every response in the middleware chain and confirm the request actually uses HTTPS.

Error
Admin route returns 200 for a plain user
Root cause

The route is registered without the authorization guard middleware.

Fix

Find the route in the inventory (grep router.*(get|post|...) and attach the guard, then re-run the probe.

Error
CSP header present but a scanner still flags XSS
Root cause

The CSP uses unsafe-inline or unsafe-eval, which weakens script-source protection.

Fix

Review script-src and object-src directives; remove unsafe-inline where the app can avoid inline scripts.

When things break

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.
Interviews

Interview checkpoint

Practice

Hands-on lab

OWASP Top 10 Hunt in WebGoat
40 min · intermediate
In progress
Objectives
  • 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

0/5 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/3
1

Which OWASP Top 10 category is 'Broken Access Control' under the 2021 refresh?

2

The OWASP Top 10 is a certification standard you must 'pass'.

3

Your scanner reports a finding with CWE-79 in the comment section. Which Top 10 category does this map to?

Quick reference

Cheat sheet

2021 Top 10 categories at a glance
A01 Broken Access ControlIDOR, missing function-level checks
A02 Cryptographic FailuresWeak hashing, plaintext secrets
A03 InjectionSQL, NoSQL, XSS (CWE-79/89)
A05 Security MisconfigurationHeaders, defaults, verbose errors
A07 Identification/Auth FailuresSession, brute force, weak creds
CWE-639 / CWE-79 / CWE-89Canonical IDs to tag findings
Go deeper

Official documentation