Exposed secrets in your client bundle: how to find and fix them

About 1 in 4 vibe-coded apps we scan has at least one credential leaked in the client bundle — usually a Stripe key, an OpenAI token, or a Supabase service-role key. The AI didn't mean to leak it; it just didn't know which keys are safe to expose. Here's how to find yours and fix it before someone else does.

What 'in the client bundle' means

When your app runs in a user's browser, everything the browser receives is public. The JavaScript bundle. The CSS. Every HTTP response. Anyone can open DevTools and read it. So any string that ends up in that bundle — even an environment variable, even a comment, even a forgotten console.log — is fully exposed to the world.

The keys most commonly leaked by vibe-coded apps

• Stripe — sk_live_... and sk_test_... secret keys. Anyone with sk_live_ can charge cards on your account, refund anything, read all customer data.
• OpenAI / Anthropic — sk-... and sk-ant-... API keys. Anyone with one can run unlimited inference on your bill.
• Supabase — service_role keys. Bypasses all row-level security; anyone has admin access to your database.
• AWS — AKIA... + secret access keys. Full account access, including provisioning resources or exfiltrating data.
• Sentry — auth tokens with project:write scope. Lets attackers tamper with your error reporting.
• Resend / SendGrid / Postmark — API keys with email-send permission. Spam from your domain reputation.
• Firebase — admin SDK keys (NOT the web config). Bypasses Firebase security rules entirely.
• Twilio — Account SID + auth token. Attacker can send SMS / make calls on your bill.

How they get there

Most leaks come from three patterns:

1. Wrong env-var prefix. Next.js exposes anything prefixed NEXT_PUBLIC_ to the client. Vite exposes anything prefixed VITE_. Vibe-coding tools sometimes default to the public prefix because it 'just works' — and the secret tags along.
2. Direct hard-coding. AI assistants occasionally inline a key as a literal string in the code, especially during refactors or when fixing a bug. 'Move this constant to the top' moves the secret into the bundle.
3. Console.log debugging. Leaving console.log(process.env) in a client component prints every env variable in the browser console.

How to check your own bundle

Method 1 — DevTools network search

1. Open your deployed site in Chrome.
2. DevTools → Sources tab → Cmd-Shift-F (Mac) or Ctrl-Shift-F (Windows) to search all loaded files.
3. Search for: sk_live_ sk_test_ sk- service_role SUPABASE_SERVICE AKIA AIza ya29. -----BEGIN
4. If anything matches in a .js or .map file, you have a leak.

Method 2 — curl + grep

For sites with many bundles, scripted check is faster:

• curl your-site.com/_next/static/chunks/*.js | grep -E 'sk_(live|test)_|sk-[a-zA-Z]|service_role|AKIA|AIza' — Next.js example
• Repeat for Vite (/assets/*.js), Remix (/build/*.js), Astro (/_astro/*.js), or whatever your framework uses.

Method 3 — Comply Code scan

Paste your URL into Comply Code. We fetch every JS bundle the page loads and grep against a corpus of ~40 known secret-prefix patterns (Stripe, OpenAI, AWS, Supabase, Anthropic, etc.). Free, no signup. The same scanner we use ships in the public Comply Code product because secret leaks were one of the four pillars of risk we initially designed around.

What to do if you find a leaked secret

Speed matters. The longer a secret is exposed, the higher the chance it's been scraped — there are automated bots that scan public sites and GitHub repos for keys 24/7.

1. Rotate the key NOW. Don't fix the code first; rotate first. Stripe / OpenAI / AWS / Supabase all have one-click rotation in their dashboards. The old key stops working immediately.
2. Generate the new key and store it in the server-only environment (Vercel env vars, Fly secrets, etc.) — never in NEXT_PUBLIC_ or VITE_.
3. Refactor the code to use the new key via a server-side route (an API route, a server component, a serverless function). The client never sees the secret.
4. Re-deploy.
5. Re-scan the deployed site to confirm the secret is gone from the new bundle.
6. Audit usage for the period the key was exposed. Stripe: check Logs for charges or refunds. OpenAI: check Usage for inference. AWS: check CloudTrail.

Preventing it on the next deploy

1. Adopt the env-var naming rule: PUBLIC variables get NEXT_PUBLIC_ / VITE_PUBLIC_; secrets do NOT. Make this a team norm.
2. Pre-commit hook to grep for known secret patterns (Stripe sk_live, OpenAI sk-, AWS AKIA). Husky + a small grep script is enough.
3. Server-side proxy pattern. The client never calls Stripe / OpenAI directly. It calls your /api/stripe/create-charge, which holds the secret server-side. This is the architectural prevention; it eliminates the leak risk entirely.
4. CI step that scans your built bundle for known prefixes and fails the build if any are found. trufflehog, gitleaks, or a hand-rolled grep all work.
5. Re-scan post-deploy. Comply Code's CI integration runs the same secret-detection check after every Vercel / Fly / Netlify deploy.

Special note: Supabase service-role keys

Supabase deserves its own paragraph. It ships two keys for every project: the anon key (safe to publish — that's its job) and the service_role key (must never touch the client). Vibe-coded apps sometimes use the service_role key because it 'just works' (it bypasses row-level security, so queries always succeed). The cost: anyone with the key reads or writes everything in your database.