Your API Keys Are Probably in Your JavaScript Bundle Right Now

Your API Keys Are Probably in Your JavaScript Bundle Right Now

GitGuardian's State of Secrets Sprawl 2026 report puts a number on something most developers already suspect but rarely check: 28.65 million hardcoded secrets were pushed to public GitHub repositories in 2025 alone, a 34% increase over the year before, and the largest single-year jump the report has ever recorded. The more uncomfortable number sits underneath that one: 64% of secrets leaked back in 2022 were still active and usable in January 2026. Nobody revoked them. They just sat there.

Why this keeps happening

Hardcoding a key isn't usually a mistake made out of ignorance. It's the fast path. A developer needs their frontend to call a third-party API, the "proper" way involves a backend proxy, environment variable management, and a bit of setup friction, and the shortcut is pasting the key straight into the component that calls it. It works immediately. It ships. Nobody circles back.

AI coding tools have made this worse, not better. GitGuardian's data shows AI-assisted commits leak secrets at roughly twice the baseline rate, and credentials for AI services specifically, API keys for OpenAI, Anthropic, and similar platforms, grew 81% year over year. Tools like Cursor, Copilot, and v0 are optimized to produce working code fast, and calling an API directly from a generated frontend component with the key inline is working code. It's just not safe code, and nothing in the generation flow flags the difference.

What it actually costs

The abstract risk is easy to wave off. The concrete cases aren't. One widely discussed example from earlier this year: a developer's Google Cloud API key, embedded in client-side code for a Maps integration, sat exposed for months without incident, then Google enabled the Generative Language API on the same project. The "harmless" Maps key suddenly granted access to Gemini endpoints too. The bill: $82,000, against a normal monthly spend of $180.

Separately, researchers at Cyble found over 5,000 GitHub repositories and 3,000 live production websites leaking ChatGPT API keys through hardcoded source and client-side JavaScript, live keys, sitting in public view, billing to someone else's account the moment anyone finds them.

Finding one doesn't require sophistication

This is the part worth sitting with: exploiting a hardcoded key isn't a hacking exercise. It's grep. Open your browser's DevTools, view the JavaScript bundle your site ships to every visitor, search for anything that looks like a key format (sk-, AIza, pk_live, and similar prefixes are all instantly recognisable to anyone who's looked before). Automated scanners do this at scale across the entire public web, continuously, for free.

How to check your own site

A few things to look for, roughly in order of how often we find them:

1. Any variable name containing key, secret, token, or password in your production JS bundle. View source, search your bundle files directly.
2. Environment variable prefixes that expose things by accident. In Next.js, anything prefixed NEXT_PUBLIC_ ships to the browser. A NEXT_PUBLIC_STRIPE_SECRET_KEY is a contradiction in terms, the prefix guarantees it's public regardless of the name.
3. API keys that were "meant" to be public but no longer are. Google Maps keys are a common example, they're designed to be restricted by domain and API scope rather than kept secret, but an unrestricted key is functionally the same risk as a secret one.
4. Old commits. Rotating a key doesn't remove it from git history. If it was ever committed, treat it as permanently exposed and revoke it rather than relying on deletion.

The fix, in order of effort

• Move the call server-side. If a key must exist, it belongs in a backend proxy your frontend calls, never in the component that ships to the browser.
• Restrict what a client-safe key can actually do. Where a key genuinely needs to be public (Maps, some analytics platforms), lock it down by domain, IP, and API scope in the provider's dashboard so a copied key is useless outside your own site.
• Rotate anything that's ever been exposed, even briefly. Revocation is the only thing that actually neutralises a leak. Deleting the file or rewriting history doesn't touch a key an attacker already has.
• Add secret scanning to your CI pipeline so a hardcoded key gets caught before it ships, not after someone else finds it.

Decloak checks your production JavaScript for exposed API keys and hardcoded secrets as part of every scan, the same class of check the researchers above ran at scale, just pointed at your own site in fifteen seconds.

Decloak checks for exposed API keys, hardcoded secrets, and vulnerable JavaScript libraries automatically, alongside seven other attack surfaces, in a free scan. Scan your site free →