Hardcoded API keys in client bundles: how they leak, and how to fix them
2026-07-12 · 6 min read
Hardcoded API keys leak when a privileged secret is compiled into browser JavaScript. It usually happens because a tutorial pattern gets copied into the wrong place, or because an AI assistant mistakes a public configuration value for a private credential. Once that code ships, anyone can inspect the bundle and recover the token.
How the leak happens
This mistake often begins innocently. A model follows a pattern from docs or Stack Overflow, adds an environment variable, imports it into a component, and wires the SDK in the browser. For genuinely publishable keys, that may be fine. For secret keys, service roles, and admin credentials, it is a serious production error.
Minification does not save you. Obfuscation does not save you. If the browser can read the bundle, a determined person can read the string.
How to fix it safely
Rotate the exposed key first. Treat it as compromised, because it was.
Then move the privileged call behind your own backend or edge function so the browser receives only the least-privileged information it actually needs.
After that, re-scan the production bundle and the repository to confirm the old value is gone. The long-term fix is simple: make bundle review part of the pre-launch routine rather than an after-the-fact scramble.
Questions builders ask
Are all keys in the client bad?
No. Some vendors issue publishable client keys on purpose. The question is whether the key can spend money, read private data, or raise privilege. If it can, it does not belong in the browser.
Will Wardloom store my key if it finds one?
Wardloom redacts secret values in findings and does not persist pasted source code. Rotate anyway, the key was already in your deploy artifact.
Ready for the last gate?
Run a defensive Wardloom scan, security, SEO, GEO, and health, then leave with a roadmap and handoff prompt.
Scan your app