Exposed API Keys and Secrets: The Vibe-Coder's First Fix

Exposed API keys are the first thing to fix in a vibe-coded app because a key sitting in code that loads in the browser can be read by anyone in under a minute, and a stolen key can be used to run up charges on your account or reach the data it unlocks. AI builders cause this constantly: the browser can't read server-side environment variables, so when the model needs a key to make the feature work, it puts the key straight into the client code. The fix is to move every credential to a server-side environment variable or a secrets manager, make sure the browser never receives it, and — because a key that has already shipped is already compromised — rotate it. This is the single highest-leverage hardening step you can take.

Why this one is first

Most security problems need someone to actively attack you. An exposed key doesn't — it's just sitting there in files your app hands to every visitor. Anyone can open browser developer tools, look at the loaded JavaScript or network responses, and copy it. From there, a stolen OpenAI or Anthropic key becomes charges on your bill; a stolen database service-role key becomes direct access to your data. There's no exploit to write. That combination — easy to find, expensive to lose — is why it's the first fix, ahead of everything else.

Why AI builders keep doing it

It's not carelessness — it's mechanics. The model's goal is code that works, and the feature needs the key to work. The browser genuinely cannot read the server's environment variables, so the path of least resistance that still "works" is to write the key into the client file. The model isn't weighing "works" against "safe," because safe was never in the objective. That's also why it happens across every AI builder rather than being one tool's bug.

The fix, in three moves

1. Move the secret server-side. Put every key in a server-side environment variable or a secrets manager. The client code should never contain the value — only your server reads it. The instruction to your AI builder: "Read this API key from a server-side environment variable and never expose it to the client."
2. Route the call through your server. If the browser was calling a third-party API directly with the key, add a small server endpoint that makes the call for it. The browser talks to your server; your server holds the key and talks to the API. "Create a server-side endpoint that makes this API call, so the browser never needs the key."
3. Rotate the exposed key. Generate a new key in the provider's dashboard, put the new one in your environment variable, and revoke the old one. Any key that was ever in client code is compromised regardless of whether you've seen abuse yet.

How to verify it's actually fixed

Don't take "done" on faith — check. Search your source code and your built/deployed bundle for common key patterns: sk- (OpenAI/Stripe-style), api_key, secret, and your provider's specific prefix. The built bundle matters as much as the source, because that's what actually ships to browsers. If a real secret turns up in either, you're not done. Then confirm the old key is revoked in the provider dashboard, not just replaced.

What this doesn't cover

Fixing secrets is the highest-leverage single step, but it's one of several. Server-side authorization, rate limits, cost ceilings, sanitized errors, and monitoring are the rest of the pass — the pre-launch check runs all six, and the mistakes catalog covers the full pattern set. Do secrets first, then work down the list; the vibe-coding security guide is the map for the whole thing.

The Vibe-Coded App Hardening Kit ($79) includes the secrets fix with the exact paste-back prompt and the manual version, plus the other nine antipatterns and a monitoring template — the highest-leverage layer for the AI-builder stack, since hardcoded-secret findings are the pattern that shows up most. It gets you to roughly production-safe; a professional review is still the separate, later step.

A leaked key is one exposure; what a model can be talked into doing with the access it already has is another. The free LLM Security Audit asks 21 questions about the second one, including how far an effect travels once something triggers it. Self-declared and unverified, not a penetration test.