Owasp Audit

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_key, MD5, SHA1, base64
• Stripe: sk_live_, sk_test_, rk_live_, whsec_
• GitHub: ghp_, gho_, ghu_, ghs_, ghr_
• AWS: AKIA[0-9A-Z]{16}, ASIA[0-9A-Z]{16}
• Google Cloud: AIza[0-9A-Za-z\-_]{35}, service-account JSON ("type": "service_account")
• Slack: xox[baprs]-, xoxe.xoxp-
• OpenAI / Anthropic: sk-, sk-ant-
• Vercel: vercel_blob_rw_
• Run via git ls-files | xargs grep -lE 'sk_live|ghp_|AKIA[0-9A-Z]{16}|sk-ant-' 2>/dev/null so binaries and gitignored files don't pollute output.
• Include non-source file extensions in the sweep. Rails cable.yml / database.yml / storage.yml, Kubernetes manifests, and Vercel / Netlify deploy configs routinely contain TLS or cert config that a source-only sweep misses. Concrete sweep for VERIFY_NONE / VERIFY_PEER:

  grep -rn "VERIFY_NONE\|verify_mode" \
    --include="*.rb" --include="*.yml" --include="*.yaml" \
    --include="*.toml" --include="*.json" \
    .

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=…>