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.

A03: Injection

• SQL injection: raw queries with string concatenation, missing parameterized queries

• NoSQL injection: unsanitized user input in MongoDB/Convex queries

• Command injection: exec(), spawn(), system() with user input

• XSS: unescaped user input in HTML, dangerouslySetInnerHTML, v-html.

• Inline-script breakout via JSON.stringify. Any <script type="application/ld+json"> or <script>window.__DATA__ = ...</script> that interpolates server data through JSON.stringify is vulnerable — JSON.stringify does NOT escape <, >, &, U+2028, or U+2029. A stored title containing </script><script>alert(1)</script> will break out. The "internal-only object" framing only saves you when every field is guaranteed never to come from user-editable input.

  • Grep for: application/ld+json, __html: JSON.stringify, window.__ + JSON.stringify
  • Fix: wrap with an escape helper that replaces <>&\u2028\u2029 with their \uXXXX Unicode escapes before injecting.

• Rails ERB sinks: raw(), .html_safe, <%==, sanitize with a permissive allowlist, and simple_format on user input. Grep for these alongside dangerouslySetInnerHTML / v-html.

• Sanitizer choice. When remediating an HTML/SVG XSS sink, the fix MUST use a vetted parser-based sanitizer (DOMPurify / isomorphic-dompurify / sanitize-html for JS; bleach for Python). Reject regex-based sanitizers in code review. If unavoidable, a regex sanitizer must:

  • Treat [/\s] (not just \s) as the attribute-name separator — HTML accepts / between tag name and first attribute: <img/onerror=…>
  • Strip both SVG- and HTML-namespace dangerous elements (, , , ) — HTML elements instantiate even in SVG-rendering contexts

A04: Insecure Design

• Authentication flows with logic flaws

• Missing rate limiting on sensitive endpoints (login, password reset, API)

• Business logic constraints only enforced client-side

• Background / fire-and-forget jobs inherit the caller's auth context but lose the request-scoped guards. Re-check authorization inside the job, not just at enqueue. Grep for: Promise.all(...).catch(, void someAsync(, .catch(noop), queue enqueue( without re-auth in the worker.

• Sister-route audit. When you find a state-machine or immutability guard on one handler (e.g., WHERE … AND signedAt IS NULL on PUT /api/foo/[id]), grep for every other handler that writes the same table:

  rg 'update\(\s*tableName\b|\.update\(tableName' --type ts -B1 -A8
  

  Each call site needs the same guard, the same userId predicate, and the same conflict-handling (returning() + 0-rows check). Common offender: a POST /:id/send or POST /:id/convert route that ships after the PUT was hardened and was never re-audited.

• External-resource-create TOCTOU with billing implications. Any handler that does "SELECT to check, then provider.create(), then INSERT to record the new resource ID" can create orphan resources on the provider side under concurrency. Stripe accounts, Auth0 / Clerk users, SendGrid templates, S3 buckets — all bill or count toward quota whether you stored the ID or not. Fix pattern:

  1. Claim first with INSERT … ON CONFLICT DO NOTHING (DB UNIQUE constraint is the lock)
  2. Call the provider
  3. Persist with optimistic guard: UPDATE … SET externalId = ? WHERE externalId IS NULL and check 0-rows
  4. On race-loss, clean up the orphan via provider.delete(id) best-effort; log on cleanup failure

• Worker-queue state transitions need atomic claim. Any cron / worker polling pending rows must atomically claim each row before processing. SELECT + process() + UPDATE is a race — two workers (or two overlapping cron invocations) both see the same pending row and both call out, causing duplicate delivery. Fix: — Postgres lets you claim and read in one round-trip. If the UPDATE returns 0 rows, someone else got it. Alternative: (Postgres / Cockroach) for higher-throughput queues.

A05: Security Misconfiguration

• Debug mode enabled in production configs

• Overly permissive CORS policies (Access-Control-Allow-Origin: *)

• Missing HTTP security headers (CSP, HSTS, X-Frame-Options, X-Content-Type-Options)

• Default credentials or configurations shipped

• Verbose error messages exposing stack traces or internals — including validation libraries echoing schema details (e.g. Zod err.issues, Joi error trees) to clients

• Baseline header starter values (paste-and-tune):

  Header	Value
  Strict-Transport-Security	max-age=63072000; includeSubDomains; preload — preload requires verifying every *.example.com serves HTTPS first
  X-Content-Type-Options	nosniff
  X-Frame-Options	DENY (defence-in-depth alongside CSP frame-ancestors)
  Referrer-Policy	strict-origin-when-cross-origin
  Permissions-Policy	camera=(), microphone=(), geolocation=(), browsing-topics=() — note interest-cohort is the legacy FLoC name (Chrome ≤ 100); current Chrome uses browsing-topics
  Content-Security-Policy	start with frame-ancestors 'self'; full CSP needs per-site script audit (inline <style>, JSON-LD, analytics)

  HSTS preload submission is sticky — removal takes months. Verify before submitting.

• Where security headers live, by framework:

  • Next.js: next.config.{js,ts} headers() block; vercel.json headers
  • Rails: config/initializers/secure_headers.rb, config/application.rb
  • Express: app.use(helmet())
  • Django: SECURE_* settings in

(Note: This bullet lives under A05 because the failure manifests as a misconfigured invariant guard. The race pattern itself spans A04 / A05 / A08 depending on framing.)

• Source-tree hygiene. Grep for sync-conflict duplicates and dead code that could let a reviewer fix the canonical file while leaving a vulnerable copy in place:

  find . \( -name '* 2.*' -o -name '* 3.*' -o -name '*.orig' \
       -o -name '*~' -o -name '*.bak' \) -not -path '*/node_modules/*'
  

  Treat findings as A05 — the canonical file may be patched while the duplicate retains the vulnerability.

• Next.js headers() rule merging. Rules in next.config.ts headers() match per route and merge — a more-specific rule does not override headers it doesn't redeclare. Shipping frame-ancestors 'none' + X-Frame-Options: DENY in a /:path* default plus frame-ancestors * in a /embed override results in both frame-ancestors * and X-Frame-Options: DENY on the embed route (contradicting; older browsers may break framing). Verify with curl -I against the deployed origin — config inspection alone misses the merge. Either set XFO in every rule or drop it entirely (CSP frame-ancestors supersedes on modern browsers).

• Auth middleware that doesn't exempt bearer/HMAC routes. Cron jobs, Stripe / GitHub webhooks, and any route that authenticates via bearer token or HMAC need to be excluded from session-cookie middleware. Symptom: those routes silently 302 to /login on every deploy or scheduled invocation, the route-level signature check never runs, and the integration appears to "work" until it doesn't.

• Bearer-token compare with unset env interpolation. Comparisons that interpolate process.env.X without a presence check — \Bearer ${process.env.WEBHOOK_TOKEN}`— resolve to a literal"Bearer undefined"when the env var is missing. An attacker who guesses the env-not-set condition can replay that literal string. Assert presence at module load:if (!process.env.WEBHOOK_TOKEN) throw new Error(...)`.

• API routes returning HTML 302 redirects instead of JSON 401. Auth middleware that 302s every unauthenticated request to breaks clients (they follow the redirect and consume HTML), obscures auth state in monitoring, and lets attackers learn endpoint existence by 302 vs 404. API routes should return with a machine-readable body.

A06: Vulnerable Components

• Run npm audit (Node), pip audit (Python), or equivalent
• Check lock files for known vulnerable dependency versions
• Flag dependencies with critical CVEs
• Run npm audit --omit=dev alongside npm audit and triage by reachability:
  • Runtime-reachable (in dependencies) — must fix
  • Build-time-only (Vite, esbuild via drizzle-kit, postcss) — usually defer
  • Dev-only (linters, test libs) — defer
• For the full CVE picture and triage by reachability, invoke dependency-audit. A06 here is a one-line sanity check.

A07: Authentication Failures

• Weak password policies
• Session management issues (missing secure/httpOnly flags, no expiry, no rotation)
• Credential-as-cookie: the cookie value is the credential (e.g. cookies.set("admin_token", process.env.ADMIN_PASSWORD) and equality-checked on read). Even with httpOnly and secure, this is plaintext-credential storage (CWE-522) and lacks rotation/revocation. Replace with an HMAC-signed expiring token verified via crypto.subtle.verify / crypto.timingSafeEqual
• Non-constant-time credential comparison: submitted === expected for passwords, API keys, or signatures leaks length and prefix-match via timing. Use crypto.timingSafeEqual (Node) or crypto.subtle.verify (Web Crypto)
• Missing rate limiting on login (credential stuffing risk)
• Broken password reset flows
• Rails / Devise — password_length requires :validatable. config.password_length in config/initializers/devise.rb is only enforced when the User model includes :validatable in its devise :... declaration. A model with devise :database_authenticatable, :registerable, :recoverable, :rememberable (no :validatable) accepts passwords of any length and any email format, regardless of what the initializer says. Grep: ^\s*devise\s+: in app/models/; flag any line where :validatable is absent. Adding it on an existing app validates on create+update but does not retro-invalidate existing weak passwords.
• NextAuth v5 / Auth.js footguns:
  • AUTH_SECRET unset silently derives a weak dev value — assert presence at module load: if (!process.env.AUTH_SECRET) throw ...
  • Credentials provider authorize() has no built-in rate limit — wrap or add upstream limiter; otherwise credential stuffing is trivial
  • Account-existence enumeration via signup error strings ("email already exists") — return a uniform "check your email" response
  • JWT strategy + DrizzleAdapter / PrismaAdapter — the adapter is a near no-op in this combination; revocation must be designed in explicitly
• Grep for: cookies.set\(.*process\.env, === .*PASSWORD, ,

A08: Data Integrity Failures

• Unsafe deserialization of user input
• Missing integrity checks on CI/CD pipelines
• No lockfile integrity verification (SRI hashes)
• External-resource overwrite without state check. Any handler that creates a provider-side resource (Stripe payment intent, subscription, webhook subscription) and stores the ID on a DB row should check whether a prior resource is still in-flight before overwriting. The old clientSecret / token may still be held by the client; on completion, the webhook handler may not find the row because the ID has changed (money lands, DB sits at processing forever). Fix: before creating a new resource, retrieve the existing one. If status is non-terminal (processing, requires_payment_method, requires_action) and parameters haven't changed, REUSE it — return the existing clientSecret. Only create a new resource when the prior one is canceled / succeeded or the parameters changed.
• External side-effects before durable DB state. When a handler both writes to the DB and triggers an external side-effect (email, charge, webhook, S3 write), the external call should come after the DB write commits. The failure mode of "DB durable, external retried" is recoverable; "external done, DB stale" is not. Fix pattern: reserve-then-act. Issue a conditional UPDATE that flips the row to the post-action state guarded by the pre-action state (WHERE status='draft'). If 0 rows, refuse. If 1 row, call the provider. On provider failure, the row already reflects intent — alert and retry. Bonus: this also makes the handler idempotent.

A09: Logging & Monitoring Failures

• Auth events not logged (login, failure, privilege changes)
• Sensitive data written to logs (passwords, tokens, PII)
• No alerting on suspicious patterns
• Silent error swallowing. Empty catch blocks hide both bugs and attack signals (rate limiter falling over, deserialization errors, auth failures).
  • Grep for: catch \{\}, catch (_) \{\}, catch (_e) \{\}, .catch(() => {}), .catch(() => null), try { ... } catch { return null }
  • Fix: at minimum log the error category (error.name, status code) without PII
• Unauthenticated endpoints sending email from a verified domain to user-supplied addresses. Any handler reachable without auth that triggers an outbound email — confirmation, password-reset to-be-claimed, invite, "we got your message" — to an attacker-supplied to: address, especially with attacker-influenced subject/body, is a phishing vector against your verified sender's deliverability reputation. Defences (pick one):
  1. Don't auto-confirm — replies happen when a human responds
  2. Require ownership proof before any reply email (verification link / double opt-in)
  3. Use a separate, plainly-templated noreply@ sender with subject/body the attacker can't influence

A10: SSRF

• User-controlled URLs passed to server-side HTTP requests
• Missing URL validation and allowlisting
• Allow-lists that only check hostname — a real allow-list must reject all of these:
  • Wrong scheme: http://allowed.com/ (when only https: is expected)
  • Embedded credentials: https://user:[e-mail]/
  • @-host trick: https://[e-mail]/ (hostname resolves to evil.com)
  • Non-default ports: https://allowed.com:8443/
  • Punycode/IDN spoof: https://аllowed.com/ (Cyrillic а) or xn--llowed-pdc.com
  • Trailing dot: https://allowed.com./ (DNS-equivalent, often missed by string compare)
  • Subdomain confusion: https://allowed.com.evil.com/
  • Bracketed IPv6 literal: https://[::1]/
  • Bare IPv4: https://127.0.0.1/
  • Decimal-integer IPv4: http://2130706433/ → 127.0.0.1
  • Hex IPv4: http://0x7f000001/
  • Octal IPv4: http://0177.0.0.1/; zero-padded 0010.0.0.1/ → 8.0.0.1 (octal!)
  • IPv4-mapped IPv6: http://[::ffff:127.0.0.1]/ → block the whole ::ffff:* range
  • Trailing-dot hostname: http://localhost./, http://metadata.google.internal./
  • Cloud metadata endpoints: AWS 169.254.169.254, GCP metadata.google.internal, ECS 169.254.170.2
  • CGNAT range: 100.64.0.0 – 100.127.255.255
  • Link-local IPv6: fe80::/10; unique-local IPv6: fc00::/7
• Fetch-time guards: redirect: "error" (don't follow attacker-controlled redirects), explicit timeout, no following 3xx into the metadata service
• Note the TOCTOU between validation and fetch — DNS can resolve differently between the two (DNS rebinding). For high-risk callers, pin the resolved IP and connect by IP with Host: header, or use a vetted proxy
• Image-optimizer-as-proxy (Next.js, Nuxt, SvelteKit): with , , or any wildcard entry lets attackers route arbitrary URLs through your CPU/bandwidth.

Verify Fixes at Runtime

After applying a fix, exercise the affected code path — do not stop at typecheck or build. Modern frameworks have runtime-only failure modes that compile cleanly:

• Edge / Node split runtimes. Next.js middleware, Cloudflare Workers, Vercel Edge — Node-only imports (node:crypto, node:fs) build successfully but throw on first request.
• Lazy module loads. Adapters/plugins loaded via import() or runtime DI surface only when the codepath runs.
• Environment-variable fallthrough. Bearer ${process.env.X} with X unset becomes a literal that the tests never hit because the test env defines X.

For each shipped fix, run the affected route or job and capture the response. tsc --noEmit + build success ≠ fix verified.

For XSS / sanitizer-config fixes, run the canonical payload set through the configured policy and confirm each is neutralized:

<img src=x onerror=alert(1)>
<a href="javascript:alert(1)">x</a>
<a href="data:text/html,<svg onload=alert(1)>">x</a>
<img srcset="javascript:alert(1) 1x,https://ok.com/a.png 2x">
<svg><script>alert(1)</script></svg>
<math><mtext></style><img src=x onerror=alert(1)></math>
<a href="//evil.com">protocol-relative</a>
<svg></svg><img/onerror=alert(1) src=x>

Second-Opinion Pass

A single-pass audit reliably catches the categories on the checklist but misses the specific bypasses that aren't in the checklist (localhost. vs localhost, IPv4-mapped IPv6, status-enumeration via ordered 404/400/401, callback-URL control chars, concurrent-execution races on paid endpoints).

After producing the first report AND after applying fixes, run a second pass with explicit adversarial framing ("assume the author is overconfident; find what they missed") — ideally with a different model or agent entirely, to break correlated blind spots. Treat any disagreement with the first pass as the higher-value finding.

Common things to find in the second pass:

• New attack surface introduced by the fix itself (auth bypass via exempted routes, IDOR introduced by a new query)
• Comments that became stale during the rewrite
• Boundary conditions in the new code (env-unset fallthrough, empty input)
• Documentation drift between the fix and the report
• Fixes that configure third-party libraries. When the fix is a snippet from a library's own docs (auth, crypto, HTTP client, rate-limit middleware), the snippet may be correct and still not run on your code path. Before declaring fixed: grep the library at the pinned version, trace from your call site to the code path the config affects. Example: enabling Better Auth's rateLimit doesn't help if you call auth.api.signInEmail(...) programmatically — that bypasses the HTTP router where the limiter attaches.

Report Format

For every OWASP category, document one of three states:

• Findings (with severity + remediation)
• Clean — explicitly state "Checked X, found no issues" with what you grepped for
• N/A — explain why the category doesn't apply (e.g. "A07 N/A: no authentication surface in this codebase")

Include an "Items checked and found clean" section in the executive summary. Audit credibility comes from proving you looked, not just from the findings list.

Findings have three possible dispositions:

• Fixed — remediation shipped in this PR. Closed pending verification.
• Deferred — remediation acknowledged and scheduled. Specify whether the next deploy is gated on it (release blocker) or not (acceptable risk with calendar fix). Severity does not change because you decided to defer it.
• Accepted Risk — remediation is NOT planned at the current configuration. The report must record:
  1. Why the fix doesn't apply — cost tier, dependency version constraint, deployment topology, vendor limitation
  2. Compensating controls — private network, signed cookies, internal-only routing, etc.
  3. Re-evaluation trigger — what condition (plan upgrade, dependency bump, traffic pattern change) would cause this finding to leave the Accepted Risk lane

An "Accepted Risk" entry without all three fields is a real finding being silently dropped under a different label.

For each finding, document:

#### [SEVERITY] A0X: [Title]
**File:** `path/to/file.ts:42`
**CWE:** CWE-XXX

**Description:** [What the vulnerability is and why it matters]

**Vulnerable Code:**
[code snippet]

**Remediation:**
[Fixed code snippet with explanation]

**Verification:** Concrete adversarial input + the command or code path that proves the fix holds. For XSS: the script-tag breakout payload that no longer breaks out. For open redirects: the off-host URL that now rejects. For password-length: the 1-char password that now fails to save. "The linter says it's fine" is not verification — static analysis has known blind spots for correctness bugs that happen to also be security fixes.

Produce an executive summary:

# Security Audit Report
## Project: [name]
## Stack: [technologies]
## Date: [date]

### Summary
- Total findings: X
- Critical: X | High: X | Medium: X | Low: X | Info: X

### Findings
[Individual findings as above]

### Prioritized Remediation Plan
1. [Critical fixes — immediate]
2. [High fixes — this week]
3. [Medium/Low — scheduled]

Boundaries

• Only audit code the user provides or points you to
• Provide fixes, not exploits — always include remediation
• Flag low-confidence findings as "Potential" rather than confirmed
• If the codebase is too large for a full audit, prioritize: auth, input handling, data access layers
• Refuse requests to insert backdoors or weaken security controls

References

• OWASP Top 10 (2021)
• OWASP Code Review Guide
• CWE Top 25