Leaked API keys in your JavaScript bundle
Everything in your frontend bundle is downloaded by every visitor. If a secret key is in there, it is public, no matter how deep it sits in a minified file. This is the most common critical finding in AI-built apps, and one of the easiest to check.
Public Runs on every scan. We only read what a browser or a public lookup would.
What it is
Modern frontends are compiled into a few JavaScript files that the browser downloads. Build tools copy some environment variables into those files on purpose: anything named VITE_…, NEXT_PUBLIC_…, REACT_APP_… or EXPO_PUBLIC_…. That is meant for public values like a site key or a Supabase anon key. When a secret gets one of those names, or is pasted straight into a component, it ships to the world.
What can happen
Anyone can open developer tools, search the bundle for sk- and copy your key. Bots do this at scale. With an AI provider key, someone runs their workload on your bill. With a Stripe secret key, they can issue refunds and read customer data. With a Supabase service_role key, they can read and change every row in your database. The damage does not need any vulnerability in your code: the key alone is enough.
How Shypset checks it
This is a Public check and runs on every scan. We load your homepage and the scripts it references, exactly as a browser does, and search them for about 40 secret formats, including:
- OpenAI and Anthropic API keys (
sk-proj-…,sk-ant-…) - Stripe secret keys (
sk_live_…) - AWS access keys, GitHub tokens, Slack tokens
- SendGrid, Mailgun, Mailchimp and Twilio keys
- Private key blocks and Supabase JWTs whose role is
service_role
Keys that are public by design, such as Stripe publishable test keys, Turnstile site keys and Firebase browser keys, are filtered out so they do not drown the real problems. Evidence in the report is always masked: we show the file, the first and last few characters and a little surrounding code, never the full key.
How to fix it
- Rotate the key at the provider first. Assume it is already copied; removing it from the code does not un-leak it.
- Move the call that needs the key to the server: an API route, a serverless function or a Supabase Edge Function. The browser calls your function, your function calls the provider.
- Rename the variable without the public prefix so the build tool stops inlining it.
- Redeploy and rescan. The finding should be gone from the diff.
Example finding
How the finding appears in a report, with a generic fix prompt.
Evidence
File: /assets/index-7c1e0b.js Match: sk-ant-api03-Hq…[masked]…x8Aw
Fix prompt
Our production bundle contains an Anthropic API key. I have revoked it. Move every call to the Anthropic API into a server-side function that reads ANTHROPIC_API_KEY from server environment variables, have the frontend call that function, and remove any public-prefixed variable (VITE_, NEXT_PUBLIC_) that holds a secret.
Questions
- Is a minified or obfuscated key safe?
- No. Minification only renames variables; the key string stays intact and is easy to search for.
- Do you store the key you found?
- No. Evidence is masked before it is saved, so the full value never reaches our database.
Check your bundle for leaked keys
Paste your URL on the home page. This check runs on every free scan.
Scan for leaked keys