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

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: vanara-agents
• Source: vanara-agents/skills
• License: Apache-2.0
• Homepage: https://vanaraagents.com

Install and usage instructions live in the source repository linked above.