/owasp-top10

name: owasp-top10
description: A deep prevention reference for the OWASP Top 10 web risks — broken access control, injection, crypto failures, insecure design, SSRF and more — with vulnerable-vs-fixed code, edge cases, and a runnable naive-vulnerability scanner.
type: skill
version: 2.0.0
updated: 2026-06-28

OWASP Top 10 Prevention

Most real-world breaches exploit a short, well-known list of weaknesses. This package is the deep reference: each category gets its root cause, the default defense, and a vulnerable-vs-fixed example. Category deep-dives live in `references/`, side-by-side fixes in `examples/`, and a runnable heuristic scanner in `scripts/`.

> Based on the OWASP Top 10 (2021). The list shifts over time, but the underlying defenses are durable.

The list (and the one-line defense for each)

| # | Category | Default defense | |---|---|---| | A01 | **Broken Access Control** | Enforce authorization server-side on every action; deny by default; check ownership (stop IDOR). | | A02 | **Cryptographic Failures** | TLS in transit; encrypt sensitive data at rest; hash passwords with argon2/bcrypt; never roll your own crypto. | | A03 | **Injection** (SQL/cmd/XSS) | Parameterize queries; context-aware output encoding; never concatenate untrusted input. | | A04 | **Insecure Design** | Threat-model before building; secure-by-design defaults; abuse-case thinking. | | A05 | **Security Misconfiguration** | Harden defaults; disable debug in prod; least-privilege; remove unused features. | | A06 | **Vulnerable Components** | Inventory dependencies; patch on a schedule; scan for CVEs (see `vuln-scanner` agent). | | A07 | **Auth Failures** | Strong session handling, MFA, rate-limit logins, no credential stuffing surface (see `secure-auth`). | | A08 | **Software & Data Integrity** | Verify signatures; secure CI/CD; don't deserialize untrusted data. | | A09 | **Logging & Monitoring Failures** | Log security events, alert on them, don't log secrets (see `audit-logging`). | | A10 | **SSRF** | Allow-list outbound destinations; validate/resolve URLs; block internal ranges. |

The two that cause the most damage

A01 — Broken Access Control (the #1 risk)

The bug: the server checks *authentication* (who you are) but not *authorization* (whether you may do this specific thing). Classic IDOR — changing an ID in the URL to read someone else's data.

// VULNERABLE: any logged-in user can read any invoice by guessing an id
app.get('/invoices/:id', auth, async (req, res) => {
  const invoice = await db.getInvoice(req.params.id);
  res.json(invoice);
});

// FIXED: authorize against ownership, deny by default
app.get('/invoices/:id', auth, async (req, res) => {
  const invoice = await db.getInvoice(req.params.id);
  if (!invoice || invoice.ownerId !== req.user.id) return res.status(404).end(); // 404 hides existence
  res.json(invoice);
});

Deep-dive: `references/access-control.md`.

A03 — Injection

The bug: untrusted input is interpreted as code/query/markup. Defense is structural separation of code from data.

// VULNERABLE: SQL injection
db.query(`SELECT * FROM users WHERE email = '${input}'`);

// FIXED: parameterized query — driver treats input strictly as data
db.query('SELECT * FROM users WHERE email = $1', [input]);

SQL, command, and XSS variants with fixes: `references/injection.md` and `examples/sql-injection-fix.md`, `examples/xss-fix.md`.

A worked SSRF case (A10)

// VULNERABLE: fetches any URL the user supplies -> attacker hits internal metadata service
const data = await fetch(req.query.url);

// FIXED: allow-list hosts and block internal ranges
const url = new URL(req.query.url);
if (!ALLOWED_HOSTS.has(url.hostname)) return res.status(400).json({ error: 'host not allowed' });
// ...plus resolve DNS and reject private IP ranges (169.254/16, 10/8, 127/8) to stop rebinding

Detail and the private-range checks: `references/ssrf-and-design.md`.

Edge cases & gotchas

• **Blocklists fail; allow-lists work.** Trying to block "bad" input (e.g. stripping `<script>`) is

whack-a-mole — encode for the output context instead, and allow-list what's permitted.

• **404 vs 403 to avoid existence leakage.** For unauthorized access to a resource whose very existence

is sensitive, return `404`, not `403`, so attackers can't enumerate.

• **Mass assignment.** Binding request bodies straight to models lets attackers set fields like

`isAdmin`. Allow-list bindable fields.

• **Second-order injection.** Stored input that's safe on the way in can be unsafe when later used in a

different context (e.g. a stored value concatenated into a query). Defend at every sink.

• **Defense in depth.** No single control is enough — combine input validation, parameterization,

output encoding, authz checks, and monitoring.

When the "fix" isn't enough

Input sanitization alone is not a substitute for parameterization/encoding — it's a fragile add-on. And security review (this skill + the `security-auditor` agent) catches code-level bugs, but design-level flaws (A04) need **threat modeling up front** (see the `threat-modeler` agent) — you can't audit your way out of an insecure design.

Files in this package

• `references/access-control.md` — A01 in depth: authz patterns, IDOR, mass assignment
• `references/injection.md` — A03: SQL/command/XSS with defenses per context
• `references/crypto-failures.md` — A02: hashing, encryption, key handling
• `references/ssrf-and-design.md` — A10 + A04: SSRF defense and secure design
• `examples/sql-injection-fix.md` — vulnerable vs parameterized, with edge cases
• `examples/xss-fix.md` — output encoding and safe rendering
• `scripts/scan-injection.mjs` — runnable heuristic scanner for naive injection patterns (selftest passes)

Pairs with the `security-auditor` agent, the `threat-modeler` agent, and the `secure-auth` and `secrets-management` skills.