API Token Leak Checker: Scan Exposed Keys in Frontend Code

What is an API token leak?

An API token leak is when an API key, secret, or access token ends up inside code that every visitor can download - usually the JavaScript bundle. Anyone who opens browser DevTools can copy the key and use it from their own machine. Automated bots do this at scale: they crawl deployed sites, GitHub, and npm packages looking for known key formats, and they find new ones every minute.

This scanner finds those keys in under 30 seconds so you can rotate before a bot does. It is intentionally narrow: credentials in the browser surface. Pair it with the Vibe Code Scanner for authz and open-database classes that are not “keys” but still dump data.

Why token leaks happen to AI-generated apps

AI coding tools - Lovable, Bolt, v0, Cursor, Claude Code, Replit - default to importing client SDKs directly into the frontend. That pattern ships your API key to every visitor. Keys that vendors label “safe for the client” (Stripe publishable, Supabase anon, Firebase config) are still abuse surfaces if the rest of your security model assumes no one has them. Keys that should never have shipped - OpenAI, Anthropic, Twilio, server-only Stripe - are catastrophic: one screenshot, one curl, and an attacker is billing your card.

Most of the vibe-coded apps we scan have at least one key in the frontend bundle that shouldn’t be there. See OWASP Top 10 for AI-generated code for the full pattern (especially A02 Cryptographic Failures).

How the generator creates the leak

1. You prompt “add Stripe payments” or “call OpenAI for chat.”
2. The model pastes the SDK example, which often includes process.env.STRIPE_SECRET_KEY or a hard-coded sk-... placeholder.
3. In Vite/Next, someone renames the var to VITE_ / NEXT_PUBLIC_ so “it works in the browser.”
4. The build inlines the value into a chunk. Deploy. Bots find it within hours.

The same loop produces service_role Supabase keys, Firebase service-account JSON, and AWS AKIA keys in public/ folders.

Host-specific accelerants

• Vercel / Next: NEXT_PUBLIC_ prefix is the classic footgun (Is Vercel Safe?)
• Vite / Bolt: VITE_ inlining
• Webflow custom code: secrets pasted into site-wide scripts (Is Webflow Safe?)
• Replit: secrets accidentally written into client files (Is Replit Safe?)
• Source maps: readable originals that make keys trivial to extract (Source Map Checker)

What the scanner checks

Additional signatures typically include SendGrid, Twilio, Slack, Mapbox, and high-entropy bearer tokens. Treat any unexpected high-entropy string in a public chunk as guilty until proven to be a public client ID.

How it works

1. Load - we fetch your URL in a real headless browser, the same way a user would.
2. Capture - every JS file, inline script, source map, and XHR response gets inspected.
3. Pattern match - 100+ known key signatures plus entropy-based detection for custom secrets.
4. Report - each finding shows the source file, line number, key type, and remediation steps.

Because the browser is real, dynamically imported chunks and lazy routes still get pulled if the page loads them. For apps that only inject secrets after a deep navigation, also exercise those routes or run a fuller app scan.

Which keys are safe in the frontend?

“Conditional” keys still need abuse controls: rate limits, referrer restrictions, and correct server-side policies. Public ≠ free-for-all.

Impact of the worst leaks

Stripe sk_live_: attacker creates charges, refunds, exports customers, changes payouts.

OpenAI / Anthropic: attacker burns your quota on cryptomining-style completions; bills hit five figures overnight without a hard cap.

Supabase service_role: full database dump/modify/delete; RLS is irrelevant.

AWS AKIA + secret: depending on IAM, full account takeover, crypto miners in your regions, public S3 dumps.

GitHub PAT: push malware to your repos, steal other secrets from Actions, pivot into org SSO apps.

Twilio / SendGrid: spam campaigns from your brand, phone fraud, reputation burn.

Rotate first, argue about severity later. Minutes matter more than perfect classification.

Common fixes

• Move keys to server-side code, edge functions, or backend proxies. The client should never hold a secret.
• For keys that must ship (Stripe publishable, Google Maps), restrict by origin/referrer in the provider dashboard.
• Rotate any key that ever appeared in a past deploy, GitHub commit, or log - bots already indexed it.
• Add a CI check that fails the build when a new token exposure is introduced.
• For Supabase, turn on RLS on every table before worrying about the anon key - RLS is the actual auth.
• Disable public source maps in production.
• Strip secrets from error pages and client-visible config endpoints.

Proxy pattern (Edge Function)

// Keep OPENAI_API_KEY only in server env
export async function POST(req: Request) {
  const session = await getSession(req);
  if (!session) return new Response("Unauthorized", { status: 401 });

  const { prompt } = await req.json();
  // rate-limit + validate prompt length here
  const r = await fetch("https://api.openai.com/v1/chat/completions", {
    method: "POST",
    headers: {
      authorization: `Bearer ${process.env.OPENAI_API_KEY}`,
      "content-type": "application/json",
    },
    body: JSON.stringify({
      model: "gpt-4o-mini",
      messages: [{ role: "user", content: String(prompt).slice(0, 4000) }],
    }),
  });
  return new Response(r.body, { headers: { "content-type": "application/json" } });
}

Local grep before every deploy

grep -rE 'sk_(live|test)_|sk-[A-Za-z0-9]{20,}|AKIA[0-9A-Z]{16}|AIza[0-9A-Za-z_-]{35}|xox[baprs]-' \
  dist/ .next/static/ --include='*.js' || true

Any hit in dist/ or .next/static/ is a ship blocker.

CI gate sketch

- name: Fail on secret-shaped strings in build
  run: |
    if grep -rE 'sk_live_|sk_test_|service_role|AKIA[0-9A-Z]{16}' .next/static dist 2>/dev/null; then
      echo "Possible secret in client build"
      exit 1
    fi

How to verify after rotation

1. Rotate the key in the provider console (disable the old one completely).
2. Remove the public prefix / move the call behind a server route.
3. Rebuild with a clean cache (rm -rf .next dist && npm run build).
4. Redeploy.
5. Re-run this Token Leak Checker on the production URL.
6. Search git history (gitleaks detect --log-opts="--all") - if the key was committed, treat it as permanently public even after rewrite unless you rotate.
7. Check provider audit logs for usage from unexpected IPs between leak and rotation.
8. Scan preview domains too - they often retain the old inlined values longer than you think.

Source maps: the silent amplifier

Production source maps (.js.map) make leaks easier to read and sometimes contain strings stripped from minified bundles. Disable public source maps for production builds, or host them behind auth for error-tracking only. The Source Map Checker flags public maps.

// next.config.js sketch
module.exports = {
  productionBrowserSourceMaps: false,
};

What this scanner does not replace

• RLS / Security Rules - a public anon key with open tables is a data breach even when no “secret” key is present. Use the Supabase RLS Checker and Firebase Scanner.
• Server-side secrets in CI logs - we only see the browser surface.
• Keys behind login returned by APIs - run authenticated testing for those.
• Mobile app binary strings - different packaging; use mobile-specific secret scanning.
• Business-logic authz - BOLA is not a token leak; use full app scanning.

Incident playbook (first hour)

1. Identify which key types appeared and in which chunk/URL.
2. Rotate / revoke those keys in provider dashboards immediately.
3. Kill billing risk: hard cap OpenAI/Anthropic; pause Stripe if needed.
4. Remove public prefixes and redeploy clean builds.
5. Audit logs for abuse between first deploy and rotation.
6. Notify stakeholders if customer data or payment rails were exposed.
7. Prevent with CI grep + ignore files + developer education on NEXT_PUBLIC_.

Do not wait for a perfect root-cause document before rotating.

Related tools and guides

• Vibe Code Scanner - full security scan of a deployed AI-generated app.
• Firebase Scanner - Firestore rules, auth, and storage bucket checks.
• Supabase RLS Checker - verify every table has a correct policy.
• Lovable Safety Guide - what Lovable ships insecure by default and how to fix it.
• Replit Safety Guide - common exposure patterns in Replit-deployed apps.
• OWASP Top 10 for AI Code - the canonical failure modes.
• Env Exposure Checker - related misconfiguration class.
• Source Map Checker - public maps that amplify leaks.
• How to Secure Vercel - NEXT_PUBLIC_ discipline.