Skip to content
Back to Quality Assurance

OWASP Top 10

Use the industry-standard list of the ten most critical web app risks as a baseline checklist.

Why

The OWASP Top 10 is not a random list — it is the consensus of thousands of reported vulnerabilities, refreshed every three to four years, ranking the risks that actually appear in real applications. Treating it as a baseline checklist ensures you have at least considered the ten most likely attack vectors before shipping. It is the lingua franca of application security: auditors, pen testers, and compliance frameworks (PCI-DSS, SOC 2) all reference it, so mapping your controls to the Top 10 makes security reviews and audits faster and more aligned. Skipping it means you are securing against the vulnerabilities you happen to know about, not the ones that actually break applications.

When

Review the current Top 10 at the start of every new project and after each major release. Map each item to a concrete control or a documented accepted risk. Re-review when the list is updated (every 3-4 years).

How

1. Read the current Top 10 (2021 edition as of writing) and understand each risk
   - A01 Broken Access Control, A02 Cryptographic Failures, A03 Injection
   - A04 Insecure Design, A05 Security Misconfiguration, A06 Vulnerable Components
   - A07 Auth Failures, A08 SW/Data Integrity Failures, A09 Logging/Monitoring, A10 SSRF

2. For each item, map it to a concrete control in your application
   - A01 → every API endpoint checks the caller owns the resource
   - A03 → all queries use parameterized inputs (no string concatenation)
   - A06 → automated dependency scan (Snyk/Dependabot) on every PR
   - If no control exists, either build one or document the accepted risk

3. Run automated scanners that map to the Top 10
   - SAST (Semgrep/CodeQL) for A01/A03/A04, dependency scan for A06
   - DAST (ZAP) for A05/A07, secret scan for A02, logging audit for A09

4. Document the mapping in a security controls matrix
   - One row per Top 10 item, columns: control, tool, status, last reviewed
   - This matrix is your evidence for audits and your gap-tracker for fixes

5. Re-review quarterly and whenever the Top 10 is updated
   - New edition may add risks (SSRF was added in 2021) — assess each new item
   - Track which controls are implemented, in-progress, or accepted-risk

Example

# docs/security/owasp-controls-matrix.md
| OWASP | Risk                  | Control                          | Tool        | Status |
|-------|-----------------------|----------------------------------|-------------|--------|
| A01   | Broken Access Control | Per-request authz middleware     | Semgrep     | ✅     |
| A02   | Crypto Failures       | No hardcoded secrets, TLS 1.3    | gitleaks    | ✅     |
| A03   | Injection             | Parameterized queries only       | Semgrep     | ✅     |
| A04   | Insecure Design       | Threat model per feature         | Manual      | 🟡     |
| A05   | Security Misconfig    | CIS benchmark scan in CI         | kube-bench  | ✅     |
| A06   | Vulnerable Components | Dependabot + Snyk on every PR    | Snyk        | ✅     |
| A07   | Auth Failures         | MFA, rate limit, bcrypt(12)      | ZAP         | ✅     |
| A08   | Integrity Failures    | Signed commits, pinned hashes    | cosign      | 🟡     |
| A09   | Logging/Monitoring    | Structured logs, alerting        | Datadog     | ✅     |
| A10   | SSRF                  | Egress allowlist, no raw fetch   | Semgrep     | ✅     |

# This matrix is the single source of truth for "are we covering the Top 10?"

Common Problems

  • ⚠Treating the Top 10 as a one-time checklist that you tick once and forget — the risks evolve, new attack techniques appear, and a control that worked last year (a regex-based input filter) may be bypassed by a new technique (polyglot payloads).
  • ⚠Mapping every item to "we have a WAF" gives false confidence — a WAF is a compensating control that catches known patterns, not a substitute for fixing broken access control or using parameterized queries at the source.
  • ⚠Focusing only on the top 3 (Injection, XSS, Broken Access Control) and ignoring A09 (Logging/Monitoring) means you may be breached and not know for months, because the detection gap is as dangerous as the prevention gap.
  • ⚠Documenting the matrix but never verifying the controls are actually effective — "we have parameterized queries" written in the matrix while a Semgrep scan finds three string-concatenated queries in production code.

Best Practices

  • ✓Map each Top 10 item to a primary control (fix at the source) AND a detection control (logging + alerting) — prevention fails, and you need to know when it does.
  • ✓Automate the verification: run Semgrep, Snyk, and ZAP in CI on every PR, and fail the build on new findings — a control that is not continuously verified is a control that has silently rotted.
  • ✓Re-read the Top 10 when a new edition is published (every 3-4 years) and assess each new or redefined risk against your codebase — the 2021 edition added SSRF and Insecure Design, which many teams had never explicitly considered.
  • ✓Share the controls matrix with the whole team, not just the security lead — developers need to know which controls exist and why, so they do not inadvertently bypass them in new code.