SECURITY / TOOL

API TOKEN LEAK CHECKER

Paste a URL. The scanner loads your live site and reads every JS bundle the browser fetched, fingerprinting 100+ key formats. If an attacker can open DevTools, they can see what we see.

/ INSTANT SCAN

FIND LEAKED API KEYS NOW

Enter your URL — we load the bundle in a headless browser and fingerprint Firebase, Stripe, AWS, OpenAI, Anthropic, Supabase, GitHub and 100+ more in under 30 seconds.

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.

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.

What the scanner checks

FIREBASE / FIRESTORE

API keys, project IDs, service account JSONs, and storage bucket credentials accidentally bundled into the client.

STRIPE

Secret keys (sk_live_…) in the frontend where only publishable keys belong, plus webhook secrets.

AWS / GOOGLE CLOUD

Access key IDs, secret keys, session tokens, signed URLs, and service-account JSON.

OPENAI / ANTHROPIC

LLM provider keys — usually mean you have exposed pay-per-token billing to the internet.

SUPABASE

Service-role keys where only the anon key belongs, and anon keys in front of tables with no RLS.

GITHUB / CI

Personal access tokens, fine-grained tokens, and CI secrets leaked through source maps or error pages.

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.

Which keys are safe in the frontend?

Key Safe in browser? Why
Stripe publishable (pk_live_…) Yes Designed to ship; restrict domain in Stripe dashboard.
Stripe secret (sk_live_…) No Full account access. Server-only.
Firebase Web config Conditional Safe only if Firestore Security Rules and Auth are correctly configured.
Firebase service account No Admin access to the entire project.
Supabase anon key Conditional Safe only if Row Level Security is enforced on every table.
Supabase service_role key No Bypasses RLS. Server-only.
OpenAI / Anthropic API key No Direct billing access. Always proxy through a backend.
AWS access key No Console and API access. Never ship to the browser.
Google Maps JS API key Yes Lock by HTTP referrer in Google Cloud Console.

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.
/ FAQ

COMMON QUESTIONS

01
What is an API token leak?
An API token leak is an API key, secret, or access token that has been shipped into code visible to end users — typically the JavaScript bundle downloaded by every visitor. Anyone who opens browser DevTools can copy the key and use it from their own machine.
Q&A
→
02
Can attackers really see API keys in my frontend code?
Yes. Any key that reaches the browser — whether inlined in HTML, bundled into JavaScript, or returned by an API call — is readable by anyone. View-source and DevTools make it trivial. Obfuscation and minification do not hide keys from automated scanners; bots index GitHub, npm, and deployed sites continuously for known key formats.
Q&A
→
03
What keys does the scanner detect?
Firebase API keys and service accounts, Stripe publishable and secret keys, AWS access keys and session tokens, OpenAI and Anthropic LLM keys, Supabase anon and service-role keys, GitHub personal access tokens, Google Maps and Cloud keys, Mapbox tokens, SendGrid keys, Twilio keys, generic JWTs, and high-entropy strings. Over 100 signatures.
Q&A
→
04
What's the difference between a Stripe publishable key and a secret key?
The publishable key (pk_live_…) is designed to ship to the browser — it can only create tokens, not charge cards. The secret key (sk_live_…) can charge, refund, and list all customers. If a secret key appears in your frontend bundle, an attacker has full control of your Stripe account.
Q&A
→
05
Is the Supabase anon key safe to expose?
Only if Row Level Security (RLS) is enabled on every table and the policies are correct. The anon key by itself is designed to be public, but without RLS it becomes a read/write key for your entire database. Most 'Supabase was hacked' stories are missing or broken RLS, not leaked keys.
Q&A
→
06
Do I need to rotate a leaked key even if no one accessed it?
Yes. Public repos, deployed bundles, and crawled pages are continuously scraped by credential-harvesting bots. If a key has been public for even a few minutes, assume it is in at least one attacker's wordlist. Rotate immediately, then audit logs from that key for anomalies.
Q&A
→
07
Is the scan safe to run on production?
Yes. The scanner loads the same URL a normal visitor would and inspects the JavaScript that was already sent to them. No additional traffic, no auth bypass, no stored results. It is a read-only fetch against your public frontend.
Q&A
→
08
How do I fix a leaked key?
Rotate the key immediately in the provider dashboard (Stripe, Firebase, Supabase, OpenAI). Move the integration behind a backend proxy or edge function so the key never ships to the browser. Rebuild and redeploy the frontend. Then search git history — if the key was ever committed, it is compromised forever.
Q&A
→
/ NEXT STEP

SCAN THE FULL APP, NOT JUST TOKENS

Get the full VibeEval agent on the same URL. RLS, auth, API fuzzing — 60 seconds to report.

RUN FULL SCAN →