How to check if your website leaks API keys

Public keys versus secret keys

Some keys are meant to be in the browser: Stripe publishable keys (pk_), Supabase anon or publishable keys, Firebase web config and map tokens. They identify your project and are limited by rules on the provider’s side.

Secret keys must never reach the browser: Stripe secret keys (sk_), the Supabase service_role or secret key, OpenAI, Anthropic, Gemini, Groq and other AI provider keys, AWS access keys, database connection strings and email API keys. Anyone who copies one can spend your money or read your data.

Build tools make leaks easy. Variables with a public prefix such as NEXT_PUBLIC_, VITE_ or EXPO_PUBLIC_ are copied into the JavaScript bundle on purpose. Putting a secret behind one of those prefixes publishes it.

How to check by hand

1. Open the live site, not localhost, because the production build is what visitors download.
2. Open developer tools, go to Sources (Chrome) or Debugger (Firefox), and search all files for sk_live, sk_test, sk-proj, sk-ant, AKIA, service_role, postgres:// and Bearer.
3. Request /.env, /.env.production and /.git/config on your domain. Each should return 404.
4. Check whether .map files load next to your JavaScript. Public source maps reveal your original source, including comments and code paths.
5. Search your git history, not only the current code, for keys that were committed and later deleted. Tools such as gitleaks or trufflehog do this.
6. Run an automated scan of the live URL so every bundle and common file path is checked the same way each time.

If you find a leaked key

1. Rotate or revoke the key in the provider’s dashboard immediately. Deleting it from the code does not help; it is already public.
2. Check the provider’s usage and billing for activity you do not recognise, and set a spending limit or budget alert.
3. Move the call that needs the key to a server route or edge function, and keep the new key in server-only environment variables.
4. Rebuild and redeploy, then rescan to confirm the old bundle and the key are gone.

Questions

Is a Google API key in my page a problem?

Usually not when it is a Firebase or Maps key restricted to your domain. It is a problem when the same key can call paid AI endpoints such as Gemini, so Defexity only reports a Google key when the page also calls the Gemini or Vertex AI API.

Will hiding the key in an environment variable fix it?

Only if the variable stays on the server. A variable with a public prefix such as NEXT_PUBLIC_ or VITE_ is bundled into the browser code.

Does Defexity store the keys it finds?

No. Evidence is masked before it is saved, so reports show only a short prefix and the length of a key.

Related Defexity checks

• SEC-016: Secret key exposed in public HTML or JavaScript
• SEC-017: Database credentials exposed to the browser
• SEC-012: Environment file publicly accessible
• SEC-013: Git repository metadata publicly accessible
• SEC-015: JavaScript source maps are public
• CODE-008: Server secret exposed through a public env prefix (code check, with GitHub)

Sources

• Next.js docs: environment variables (opens in a new tab)
• Vite docs: env variables (opens in a new tab)