/owasp-audit

name: owasp-audit
description: "Audit application source code against the OWASP Top 10 (2021) vulnerability categories — broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable components, authentication failures, data integrity, logging failures, SSRF. Use when the user mentions 'OWASP,' 'OWASP Top 10,' 'security audit,' 'security review,' 'secure code review,' 'code security review,' 'vulnerability audit,' 'find vulnerabilities,' 'appsec review,' 'application security audit,' 'check for security issues,' 'broken access control,' 'IDOR,' 'SQL injection,' 'XSS,' 'SSRF,' or wants to check their codebase for common security weaknesses."
allowed-tools: Read, Grep, Glob, Bash, Write

OWASP Audit — Source Code Security Review

Perform a systematic security audit of application source code against the OWASP Top 10 (2021).

Scope the Audit

1. Identify the project's language, framework, and architecture 2. Map entry points (routes, API handlers, form processors) 3. Identify data flows (user input → processing → storage → output) 4. Locate authentication and authorization boundaries

Audit Checklist

Work through each category systematically. For each, grep for known vulnerability patterns, then read flagged files for deeper analysis.

A01: Broken Access Control

• Missing authorization checks on endpoints or routes
• IDOR — user-controlled IDs without ownership verification
• **Auth-check ordering.** Verify the authorization check runs *before* any branch that can reveal whether the resource exists, what state it's in, or any other resource-specific metadata. Returning 404 for "not found", 400 for "wrong state", and 401 for "not authenticated" is itself a leak — an attacker enumerates resource IDs and learns states without ever passing the auth gate. Recommended response shape: uniform 404 for everything an unprivileged caller should not see.
• **Framework RPC surfaces that don't appear as routes.** Server actions and equivalents are publicly-exposed RPCs that file scans miss. Enumerate and audit each one for auth + ownership:
• Next.js: every exported function in a file with `'use server'`
• Remix / React Router: every `action` / `loader` export
• tRPC: every procedure
• GraphQL: every resolver
• Rails: non-resource controller actions
• **IDOR via foreign keys in mutation payloads.** Form posts a foreign-key UUID (`categoryId`, `projectId`, `teamId`, `organizationId`) → server validates ownership of the primary record but blindly accepts the FK → ORM relation join later surfaces another tenant's data. Look for `formData.get("<id>")` / `body.<id>` passed straight to insert/update without a preceding `findFirst({ where: { id, userId } })`. For ORM relation joins (Drizzle `with:`, Prisma `include`, ActiveRecord `includes`), trace whether the join target is filtered by the same tenant/ownership predicate as the parent query.
• Missing CSRF protections on state-changing requests
• Role checks only on the frontend, not enforced server-side
• Open redirect via post-auth return-to parameter — `?from=`, `?next=`, `?returnTo=`, `?continue=`, `?redirect=` passed unsanitized to `redirect()` / `Response.redirect()`. Restrict to same-origin paths under the expected scope, normalize (`new URL(target, "http://localhost").pathname`) to defeat traversal like `/admin/../foo`. Also reject control bytes in the path before redirect: tab/newline/null (`\t`, `\n`, `\0`) — URL parsers strip these and collapse `/\tevil` into protocol-relative `//evil`; null bytes can turn the redirect into a 500. Reject any byte in `[\x00-\x1F\x7F]`, any backslash, and any percent-encoded slash/backslash (`%2f`, `%5c`).
• Grep for: direct object references, missing auth middleware, user ID from request params, `redirect(.*from`, `redirect(.*next`, `redirect(.*returnTo`

A02: Cryptographic Failures

• Hardcoded secrets, API keys, or passwords in source
• Weak hashing (MD5, SHA1 for passwords instead of bcrypt/argon2/scrypt)
• For bcrypt, also check the cost factor. OWASP 2024 guidance is ≥ 12 (cost 10 ≈ 10ms / 100 hashes/sec/core for an attacker)
• **Type coercion in cryptographic-verification paths.** Numeric parsing (`parseInt`, `Number`, `parseFloat`) silently produces `NaN` for garbage input, and `NaN` compares as `false` for both `<` and `>`. A timestamp-freshness check `if (Math.abs(now - parsed) > tolerance) return false` *fails to reject* `NaN` — because `NaN > tolerance` is `false`. Grep for: `parseInt|parseFloat|Number\(.*\)` inside `verifySignature` / `validateToken` / signed-cookie / JWT-claim code. Each numeric extraction must be followed by `if (!Number.isFinite(parsed)) return false` before any inequality. Same family: `parseInt('0x123', 10) === 0`, `parseInt('1e10', 10) === 1`, `parseFloat('Infinity') === Infinity`.
• Sensitive data in logs, URLs, or localStorage
• Missing encryption at rest or in transit
• **Before recommending `VERIFY_PEER` for a TLS connection,** identify the cert issuer at the deployment target. Many managed services ship self-signed cert chains at lower tiers (Heroku Redis Mini/Hobby, some ElastiCache configurations, Supabase legacy) — `VERIFY_PEER` fails there without an explicit `ca_file:` pin. When `VERIFY_PEER` is genuinely infeasible, present three remediation options in priority order:

1. Upgrade the plan or pin the CA bundle — restores cert verification 2. Accept the risk explicitly — leave `VERIFY_NONE` with (a) an in-line comment at every call site, (b) a documented compensating control (private network, internal-only routing), (c) a follow-up issue tracking re-verification conditions 3. Restrict the network path — private subnet / VPC peering / no public exposure

Never quietly recommend `VERIFY_PEER` without checking that the cert chain at the deployment target is verifiable.

• Grep for generic secret names AND known provider key prefixes:
• Generic: `password`, `secret`, `api_key`, `private