// security check

Exposed API key scanner: find leaked secrets in your app

Short answer

If a secret key (Stripe `sk_live_…`, OpenAI, AWS, a database URL, or a Supabase service_role key) ends up in your frontend code or a public env variable, anyone can open dev tools and take it. CodeCheck scans your live app's JavaScript and network traffic for leaked secrets and tells you which ones to rotate now.

Check my app — free

An exposed API key scanner finds secret keys that leaked into the part of your app the public can see. In a web app, everything shipped to the browser — your JS bundles, inline scripts, and env variables prefixed for the client — is fully readable by anyone. A secret placed there isn't hidden; it's published.

This is one of the most expensive mistakes in AI-built apps because the tools happily wire a secret straight into client code to "make it work." A leaked Stripe secret key can drain a business; a leaked OpenAI key can run up thousands in usage overnight.

Which keys are secret vs. safe to expose

Not every key is a secret. Knowing the difference stops false panic and real leaks:

SECRET — never in the browser: Stripe sk_live_/sk_test_, OpenAI/Anthropic keys, AWS access keys, database connection strings, Supabase service_role key.
PUBLIC — safe in the browser by design: Supabase anon/publishable key, Firebase web API key, Stripe publishable pk_ key.
The rule: if a key can act on your account with full privileges, it belongs only on the server.

How keys leak in Next.js and Vite apps

The most common cause is the client-side env prefix. In Next.js, any variable starting with NEXT_PUBLIC_ is inlined into the browser bundle. In Vite it's VITE_. Putting a secret behind those prefixes publishes it.

Wrong vs. right

# WRONG — ships to the browser, readable by anyone
NEXT_PUBLIC_OPENAI_API_KEY=sk-...

# RIGHT — server-only, never sent to the client
OPENAI_API_KEY=sk-...

What to do the moment you find a leaked key

Hiding the key is not enough — assume it's already compromised the instant it was public.

Rotate (regenerate) the key at the provider immediately; the old one may already be scraped.
Move the key to a server-only environment variable and call the provider from an API route, not the browser.
Check provider usage/billing for unexpected activity.
Purge the key from git history if it was ever committed.

Frequently asked questions

How do I know if my API key is exposed?

Open your live site, open browser dev tools, and search the loaded JavaScript for the key or its prefix (sk_, sk-, AKIA, etc.). If it's there, it's public. A CodeCheck scan automates this across all your bundles and network requests and reports exactly which secrets leaked.

Is it bad if my API key is in the frontend?

It depends on the key. Publishable/anon keys (Supabase anon, Firebase web key, Stripe pk_) are designed to be public. Secret keys (Stripe sk_, OpenAI, AWS, service_role) must never be in the frontend — if they are, rotate them immediately and move them server-side.

Someone found my key — what now?

Rotate it right away at the provider so the leaked value stops working, move it to a server-only variable, check your billing/usage for abuse, and remove it from any public code or git history.

See exactly what's exposed — in about a minute.

Paste your link. CodeCheck checks your live app the way a hacker would and hands you the fix in plain English. Free to start, no card.