Security · Deployment guide
How to check if secrets leaked into your frontend bundle
Short answer
Anything bundled with a NEXT_PUBLIC_ or VITE_ prefix is shipped to every visitor's browser. A single grep on your compiled output tells you whether a secret slipped through. If you find one, rotate first, then fix.
Symptoms
- Suspicion that a server-only key (Stripe sk_, Supabase service_role) was given a public prefix.
- Security scanner flagged exposed credentials.
- API quota burning faster than expected — abuse from leaked key.
- Pre-launch checklist requires a secrets audit.
Common causes
- Server-only key copy-pasted into a NEXT_PUBLIC_ / VITE_ variable.
- Key used in a React component or hook (client-side code path).
- Hard-coded fallback in source: <code>const KEY = process.env.X || "sk_..."</code>.
- Build inlines a server config file into a client component import graph.
How DeployDoc checks this
- Scans .next/, dist/, build/ for known secret prefixes (sk_, sk-, sk-ant-, eyJ, AKIA, AIza, gh_, slack_).
- Flags every NEXT_PUBLIC_ / VITE_ variable whose value matches a server-secret pattern.
- Traces server-only imports reachable from client components.
- Verifies .env.example doesn't contain real values that may have been committed.
Fix it manually
- Build production locally:
npm run build. - Search the output:
grep -RE "(sk_|sk-ant-|eyJ|AKIA|AIza)" .next/ dist/ build/. - For any match: rotate the key in the provider dashboard first.
- Remove the variable from public scope; move usage to a server function or API route.
- Redeploy and re-grep to confirm the bundle is clean.
When to run a DeployDoc diagnosis
Before every public launch, after rotating any credential, and any time you add a new third-party API key.