Your API key is exposed: what happens, what to do, how to prevent it

What it actually is

An exposed API key is a secret credential (a string like sk-proj-... for OpenAI or sk_live_... for Stripe) sitting somewhere a stranger can read it: a public GitHub repo, your site’s JavaScript bundle, a screenshot pasted into a forum. Think of it like writing your house key’s shape on a sign taped to your front door. The key isn’t a setting, it’s proof of identity. Whoever holds it can act as you, because the API has no way to tell “you” apart from “someone who has your key.” It’s not a bug you can quietly patch: from the moment it leaks, anyone on the internet can spend your money or read your data.

Why your AI just did this

Your agent hardcodes the key because it’s the fastest way to make the feature work right now: it writes Authorization: Bearer sk-... straight into a .js file that calls OpenAI, or drops STRIPE_SECRET_KEY = "sk_live_..." into a script, because that unblocks the demo. Agents optimize for “the button works,” not “this is safe to ship.” Nobody told it otherwise. Frontend code is a special trap: anything that runs in the browser is downloaded to every visitor’s machine and readable via View Source or the DevTools Network tab, so a key placed there is public the second you deploy, no hacking required. Agents also commit .env files to git by default if a .gitignore wasn’t set up before the very first commit, which quietly ships your secrets to GitHub along with your code.

When you’ll run into it

• GitHub’s secret scanning blocks your git push outright, or emails you after the fact, because it “found a hardcoded OpenAI key in a vibe-coded app” you just committed.
• You check your OpenAI or Anthropic billing dashboard and see usage or spend you didn’t generate, sometimes overnight.
• Stripe auto-revokes a key it detected in a public repo (you “left Stripe API keys public” without meaning to), and your live payments suddenly fail with an “invalid API key” error.
• You open your deployed site, hit F12, click Network, and there’s your own secret key sitting in a request header for anyone to copy.
• A teammate or a random GitHub user opens an issue asking, politely, whether you meant to commit that key.

What to check

• Search the whole repo before committing: grep -r "sk-" . (adjust the pattern per provider) catches most hardcoded keys. Also eyeball any file that talks to an external API.
• Confirm .env is listed in .gitignore and was already ignored before your first commit. Git still remembers files it tracked earlier, even after you add them to .gitignore.
• Treat any key that ever touched a public repo as burned: rotate it from the provider’s dashboard immediately, even after deleting the commit. The old value stays readable in git history.
• Make sure secret keys are only called from server-side code, never shipped to the browser; if the provider offers a public/publishable key (Stripe’s pk_ keys, for example), use that on the frontend instead.
• Set spend limits or usage alerts in the provider’s dashboard so a leaked key can’t run up an unlimited bill before anyone notices.

Say it like a dev

Instead of: “Add the OpenAI key so the app works.” Say: “Put the OpenAI key in an environment variable, not hardcoded in the file.”

Instead of: “Why did Stripe stop working after I pushed to GitHub?” Say: “Check if Stripe revoked my key because it was exposed in a commit. If so, help me rotate it and move it into .env.”

Instead of: “Make the frontend call the API directly.” Say: “Route this call through a backend endpoint so the secret key never reaches the browser.”