Security Audit

Security Audit

Purpose

Identify and fix frontend-side security vulnerabilities using OWASP Top 10 as the checklist. Defense-in-depth: no single fix solves all attacks — combine output encoding, CSP, sanitization, and server-side enforcement.

Universal — OWASP, CSP, RLS, env-leak detection, and auth-token storage rules apply to all stacks; only the framework-specific syntax differs (NEXT_PUBLIC_ vs VITE_ vs PUBLIC_).

Procedure

1. Context-aware output encoding (OWASP core teaching)

   • The right encoding depends on the context where untrusted data lands:
     • HTML body: React auto-escapes when used as JSX text content (<div>{userInput}</div> is safe)
     • HTML attribute: React escapes for attribute values; danger appears in template-literal class names or style props
     • JavaScript context: never inject untrusted data into <script>, eval(), setTimeout(string)
     • CSS context: never inject into style attribute as a string — use object syntax
     • URL context: validate URL schemes (reject javascript: / data: for hrefs); allowlist redirect targets — a ?redirect= / returnTo param fed into router.push() or <a href> is an open-redirect (phishing) vector
   • React's auto-escape covers HTML body but NOT the other 4 contexts — explicit handling required

2. Sanitize any raw-HTML injection sink before render — better, avoid raw-HTML injection entirely (use text content)

   • Locate every raw-HTML sink and confirm each sanitizes untrusted input before it is written to the DOM
   • Best: avoid the raw-HTML path altogether by rendering as escaped text content
   • (React dangerouslySetInnerHTML + DOMPurify — see Implementation)

3. Never put secrets in client-bundled env vars; audit the client-prefixed vars for keys/tokens

   • Any env var with the client-bundle prefix is shipped to the browser — never put secrets there
   • Audit every client-prefixed var → verify no API keys, tokens, or secrets leak into the bundle
   • Server-only secrets: unprefixed env vars, accessed only in server-side code
   • Also audit other client-side leaks: production source maps served publicly (exposes original source), PII/tokens in console.log, secrets passed in URL query params (logged in server/referrer/analytics)
   • (Next NEXT_PUBLIC_* — see Implementation)

4. Audit token storage

   • Banned: auth tokens in localStorage or sessionStorage (XSS-readable)
   • Required: HttpOnly + Secure + SameSite cookies for auth tokens
   • Audit: grep -rn 'localStorage.*token\|sessionStorage.*token' src/

4b. Protect cookie-based auth against CSRF

• Cookie auth (step 4) is sent automatically on cross-site requests → CSRF risk. SameSite=Lax (or Strict) blocks most cases but NOT all (SameSite=None integrations, some cross-site POST contexts)
• For state-changing requests, also verify the request origin server-side: a CSRF token (double-submit) or an Origin / Sec-Fetch-Site check
• Header-based tokens (Authorization) aren't CSRF-prone — but they live in JS memory, so don't reintroduce the localStorage problem from step 4

5. Detect code-execution sinks

   • eval(), new Function() — should never appear
   • setTimeout('string'), setInterval('string') (string form, not function form)
   • Search and eliminate

6. Verify CSP headers

   • Content-Security-Policy set with at minimum:
     • script-src 'self' [trusted CDNs] (no 'unsafe-inline' or 'unsafe-eval')
     • object-src 'none'
     • frame-ancestors 'none' (or specific allowlist)
   • For inline scripts (required by Next.js): use nonce-based CSP
   • Enable Trusted Types where supported (Chrome/Edge):

     Content-Security-Policy: require-trusted-types-for 'script'; trusted-types default
     

     Forces all DOM sink writes (innerHTML, etc.) to go through a Trusted Types policy.
   • Add Subresource Integrity (integrity + crossorigin) to third-party CDN <script>/<link> so a compromised CDN can't swap in malicious code (coordinate with third-party-scripts)

7. Enforce authentication AND authorization server-side — client checks are decorative/bypassable

   • Authentication (who are you): a client-only if (!user) redirect() is always bypassable; the server must verify the session on every protected route
   • Authorization (can you touch this resource): OWASP's #1 category. Even when authenticated, verify object ownership on every request — /api/orders/123 must confirm order 123 belongs to the caller (IDOR / broken object-level access control). The UI hiding a link is not access control
   • For Supabase, RLS (step 8) enforces ownership at the DB; for custom APIs the per-resource ownership check is explicit in each handler
   • Audit all protected routes/handlers for both checks
   • (requireUser() + per-resource ownership check — see Implementation)

8. Enable row-level security on every user-data table; verify policies aren't using (true); keep public tables few

   • All user-data tables must have row-level security enabled
   • Verify policies are correct (not an open using (true))
   • List public tables explicitly — there should be very few
   • (Supabase RLS — see Implementation)

9. CORS audit

   • No wildcard Access-Control-Allow-Origin: * for endpoints that accept credentials
   • Allowlist specific origins

10. Validate env at build via a typed schema (fail the build, not production runtime)

• Validate env against a typed schema so missing or malformed values fail the build, not production at runtime
• (@t3-oss/env-nextjs — see Implementation)

11. Verify with automated tooling (validation loop)
    • Run a security linter over the codebase; if violations, evaluate each (true positive → fix; false positive → suppress inline with a comment) and re-run until clean
    • Run a dependency vulnerability scan; if Critical/High vulnerabilities, patch (auto-fix or manual version bump) and re-run; if no patch available, document and accept the risk with reason
    • Re-test all fixes — security fixes that break functionality are not fixes
    • (eslint-plugin-security / npm audit — see Implementation)

Anti-patterns

Severity tiers

Completion Criteria

• All dangerouslySetInnerHTML sanitized via DOMPurify
• No secrets in NEXT_PUBLIC_* env vars
• No auth tokens in localStorage / sessionStorage
• Cookie-auth state-changing requests have CSRF protection (SameSite + origin/token check)
• CSP headers configured (no unsafe-inline/unsafe-eval for script-src)
• All protected routes verified server-side (authentication)
• Object-level authorization checked server-side (no IDOR) — not just authentication
• Redirect / returnTo params allowlisted (no open redirect)
• RLS enabled on all user-data Supabase tables
• Env variables validated via Zod schema
• All Critical findings fixed; all Major findings scheduled

Stop & Ask (AI must pause for user approval)

• Before applying any Critical fix that touches auth, RLS, or session handling — these changes can lock users out if wrong
• Before changing CSP headers in production-affecting config (one bad nonce = blocked scripts)
• Before bulk dependency upgrades triggered by npm audit fix (can introduce breaking changes)

Output

• Report: docs/security-audit-YYYY-MM-DD.md with sections:
  • ## Summary — counts by tier (Critical / Major / Minor)
  • ## Critical findings — per finding: file:line, category, exploit scenario, fix
  • ## Major findings — same format
  • ## Minor findings — same format
  • ## Verification — tools used, commands run, validation loop results
• Code changes: separate commits per fix; commit message format fix(security): <description> [severity: critical|major|minor]
• CSP header config: update in next.config.ts (or equivalent) with a comment linking to the audit report

Implementation

React + Next.js (default)

• Client-bundled env prefix: NEXT_PUBLIC_* — never put secrets here
• Sanitization: DOMPurify for dangerouslySetInnerHTML
• Server enforcement: Server Components / Route Handlers / Server Actions with requireUser() middleware
• Authorization: check resource.userId === session.user.id in every handler (no IDOR); RLS for Supabase tables
• CSRF: SameSite=Lax/Strict cookies + verify Origin / Sec-Fetch-Site (or a CSRF token) in Server Actions / Route Handlers for mutations
• Source maps: keep productionBrowserSourceMaps: false (default) — don't ship original source to the public
• CSP: next.config.ts headers() function; nonce-based for inline scripts
• Env validation: @t3-oss/env-nextjs (Zod schemas)
• Database: Supabase RLS (Row Level Security policies)

Other stacks

• Vue / Nuxt: client-bundled prefix NUXT_PUBLIC_*; sanitization v-html + DOMPurify; CSP via nuxt.config.ts routeRules
• SvelteKit: client-bundled prefix PUBLIC_*; sanitization in +page.svelte with DOMPurify; CSP via svelte.config.js csp option
• Vite (any framework): client-bundled prefix VITE_*
• Angular: built-in sanitization via DomSanitizer (don't bypass); CSP via meta tag or server header
• All stacks: HttpOnly + Secure + SameSite cookies for auth tokens; never localStorage
• OWASP categories (LLM, OAuth, API) — framework-independent; apply directly

Related skills

• accessibility-audit — some aria attrs (aria-*) carry security weight too
• developer-experience — env validation (@t3-oss/env-nextjs) is set up there
• third-party-scripts — SRI, CSP, and consent for external/CDN scripts
• cicd-pipeline — wire npm audit and CSP regression tests into CI

Reference

• Key insight encoded: Output encoding alone is insufficient — combine context-aware escaping, DOMPurify sanitization, nonce-based CSP, and Trusted Types as defense-in-depth. Client-side protection is decorative; server-side enforcement (RLS, requireUser(), env validation at build) is what actually secures the application. Two easily-missed gaps: cookie auth (the recommended token storage) needs CSRF defense (SameSite + origin/token), and authentication ≠ authorization — verify object ownership per request or you ship IDOR (OWASP's #1).