Secrets

The most common way API keys leak from production sites

Keys do not leak the way people imagine

When a key leaks, it is rarely a clever breach. It is almost always the same quiet mistake: a credential that belongs on the server gets used in the browser, and the browser downloads everything. Here is where it actually happens, most common first.

1. Hardcoded in the frontend bundle

This is the number one source. You need to call an API — payments, AI, maps, email — and the quickest path is to use the key right there in the client code. It works perfectly in testing. But that code is bundled and served to every visitor, so the key is now sitting in your JavaScript for anyone to read. Naming the variable secretKey changes nothing; the browser still has it.

2. Source maps

Even if the key is buried in minified code, a published source map (.js.map) reverses the minification and hands over your original source, key and all. Source maps are a development aid that should not ship to production.

3. Committed config that becomes public

A key gets committed to a config file — .env, appsettings.json, a settings module — and then that file is deployed into a public folder, or the repository is public. Now the key is one predictable URL or one git clone away.

4. HTML comments and inline scripts

The overlooked one: a key pasted into an inline <script> or left in an HTML comment during debugging, then shipped. It never even makes it into a bundle — it is right there in the page source.

How fast does this get found?

Fast. Automated bots continuously scan freshly deployed sites and public code repositories for known key formats — AWS, Stripe, OpenAI, GitHub and dozens more all have recognizable shapes. A key exposed in your frontend is typically found and catalogued within minutes of going live, long before you would notice anything wrong.

The fix is always the same shape

  • Keep keys on the server. Put the third-party call behind your own backend endpoint, so the browser talks to you and only your server holds the key.
  • Use restricted keys where you can. Many providers offer publishable or scoped keys for the few things that genuinely must run client-side — use those, never the powerful secret key.
  • Do not ship source maps to production, or upload them privately.
  • Rotate anything that was public. If a key was ever reachable in your frontend, treat it as already leaked: revoke it, issue a new one, and check the provider logs for unexpected use.

Check what your site exposes

The uncomfortable part of leaked keys is that you cannot eyeball a two-megabyte bundle. An automated scan reads your pages and scripts the way a bot would and tells you if a key is reachable — scan your site and find out before someone else does.

Related reading

FAQ

Is it safe to put any key in frontend code?
Only keys explicitly designed to be public — publishable or scoped client keys, like a Stripe publishable key or a domain-restricted maps key. Any secret or full-access key must stay server-side, behind your own endpoint.
I found a key in my bundle — what now?
Treat it as compromised. Revoke and rotate it, move the call server-side, then check the provider's usage logs for activity you do not recognize. Do not just delete it from the next build and hope.
Do private repositories keep my keys safe?
Better than public ones, but it is not a strategy. Repos get opened up, forked, or leaked, and the key still ends up in any build that ships it to the browser. Keep secrets out of code and in server-side configuration or a secrets manager.