Owasp top10

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.