Tom Hundley
🤖 Ghostwritten by GPT 5.4 · Fact-checked & edited by Claude Opus 4.6
If you build apps with AI tools like Cursor, Bolt, or Replit, the most dangerous security mistake is putting API keys and other secrets where users, browsers, repos, or AI assistants can see them. That single mistake can turn a working prototype into a billing disaster, a data exposure event, or both. The fix is not complicated, but it requires changing a few habits immediately.
The warning signs are no longer theoretical. In its 2025 State of Secrets Sprawl report, GitGuardian detected 28.65 million new secrets on GitHub. The same report found that repositories with Copilot-enabled commits showed secret leakage at roughly double the baseline rate. Separately, public reporting described a case where exposed Google Gemini API credentials led to roughly $82,000 in unauthorized usage, and reporting around exposed client-side code at Moltbook highlighted how easily API keys can be harvested at scale. For non-developers using AI to build software, the lesson is clear: if a secret touches the frontend, a public repo, a screenshot, or an AI prompt without guardrails, treat it as already compromised.
TL;DR: If your app user can download it, inspect it, or view it in the browser, any API key inside it is effectively public.
A secret is any value that grants access: API keys, database passwords, OAuth client secrets, webhook signing keys, private tokens, and service credentials. For vibe coders, the most common failure is assuming that because a key is hidden in a settings panel, a JavaScript file, or a low-code builder, it is safe. It is not.
Here is the plain-English rule: if code runs in the browser, the browser can reveal it. If code is pushed to GitHub, the repo history can preserve it. If a key is pasted into an AI coding assistant chat, that key has left its safe storage location. None of that requires an especially advanced attacker.
The Google Gemini API theft story illustrates how expensive a simple mistake can become. When an API key is exposed client-side or committed into a repository, someone can copy it and use it from somewhere else. The bill still goes to the original account owner. API key security is not just a technical issue—it is a cost-control issue.
For API key leak prevention, all of these are unsafe places for real secrets:
| Location | Safe for real secrets? | Why |
|---|---|---|
| Browser-based frontend code | No | Users can inspect network calls and source files |
| Server environment variables | Yes | Secrets stay on the server, not on the client |
| Secret manager or platform secrets panel | Yes | Designed to store and inject credentials securely |
| Git repository source files | No | Commits, forks, and history can expose them |
Local .env file excluded from git |
Usually yes | Safer for development if not committed or shared |
The most important mindset shift: hiding is not the same as securing. Obscure code is still readable code.
TL;DR: Secrets leak because AI tools optimize for "make it work," while beginners often do not yet know which shortcuts are unsafe.
Vibe coder security problems usually start with speed. A builder asks Cursor to "connect Stripe," "add Gemini," or "set up Supabase auth," and the assistant tries to produce a working result quickly. If the prompt does not explicitly require secure handling, the model may suggest hardcoding a key, placing it in a config file, or wiring it into frontend code just to get the feature running.
That is not always because the tool is broken. It is often because the model predicts a likely completion from patterns it has seen, and many public code examples on the internet are not production-safe. AI coding assistant security matters because assistants can reproduce insecure examples faster than a beginner can recognize them.
GitGuardian's 2025 finding is especially relevant: 28.65 million new secrets were detected on GitHub, and repositories with Copilot-enabled commits leaked at about twice the baseline rate. That does not mean AI coding tools are inherently unsafe. It means assisted coding increases output speed, and insecure output scales just as fast as secure output.
This happens when a user pastes a real key into the prompt and asks the tool to "hook everything up." The assistant may insert the key into a JavaScript constant, config file, or test script.
Bolt and Replit security issues often appear when builders start with a browser-based prototype. If the app directly calls a paid AI API from the browser, the key must travel to the browser too—meaning anyone can extract it.
Deleting a key from the latest file is not enough if it was already committed. Git history may still contain the secret. Forks, clones, and cached copies can keep it exposed even after the visible file looks clean.
Many beginners hear "just add .env to .gitignore" and assume the problem is solved. That helps, but only for files that were never committed in the first place. If a secret was already tracked once, .gitignore does not remove it from history. And if an AI assistant copies the value into another file, the ignore rule does nothing.
Secrets management needs more than one layer:
TL;DR: Move every secret into environment variables or a secrets manager, keep API calls on the server, and rotate anything that may already be exposed.
The fastest practical fix is to stop treating keys like app settings and start treating them like passwords.
If a key has ever been:
rotate it now. Do not wait for signs of abuse. Most providers let you revoke old keys and create new ones in minutes.
Environment variables are values stored outside your code and injected at runtime. They let your app access a secret without saving it in the source file.
Use this pattern:
.env file.envExample pattern:
const apiKey = process.env.GEMINI_API_KEY;
if (!apiKey) {
throw new Error("Missing GEMINI_API_KEY");
}For Cursor, review generated files before accepting them and search for suspicious patterns like sk-, AIza, apiKey, secret, token, and password.
For Replit, use the platform's Secrets feature rather than plain files whenever possible. For Bolt, verify whether generated integrations are running server-side or exposing credentials in browser code.
This is the rule that prevents many expensive mistakes. The browser should call your backend. Your backend should call the AI provider.
That way:
Use git secret-scanning tools before pushes and in your repository host. GitHub's push protection, for example, can block commits that contain recognized secret patterns before they become public.
At minimum, search your codebase for:
api_keysecrettokensk-, AIza)If you committed a secret, removing the line is only the first step. You may need to rewrite git history using tools like git filter-repo or BFG Repo-Cleaner—and then rotate the key anyway. Rotation is still essential because someone may already have copied it.
TL;DR: Good prompts reduce insecure output by telling the model exactly how to handle secrets before it generates code.
One of the easiest API key leak prevention tactics is to change the prompt itself. Do not ask the assistant to "just make it work." Ask it to make it work securely.
Use a prompt like this:
Build this feature using secure defaults.
Requirements:
- Never hardcode API keys, tokens, passwords, or secrets in code.
- Use environment variables for all secrets.
- Keep all third-party API calls that require secrets on the server side.
- Do not place secrets in frontend code, client bundles, logs, tests, or example files.
- If a secret is needed, show a placeholder like YOUR_API_KEY and explain where it should be stored.
- Assume the repository may become public, so generate code that is safe for public source control.
- Add input validation and basic error handling.
- Tell me explicitly which files are safe to commit and which must stay local.
- Before finishing, list any security risks or secret exposure risks in the generated solution.This works because it changes the model's optimization target. Instead of optimizing only for speed, it now optimizes for secure structure.
| Question | If the answer is yes | Action |
|---|---|---|
| Is a real key visible anywhere in code? | The secret is exposed | Remove it and rotate the key |
| Does browser code call a paid API directly? | Users can likely extract the key | Move the call to the backend |
| Was a secret ever committed to git? | History may still contain it | Rotate and clean history |
| Did the AI assistant generate sample secrets that look real? | They may be copied later by mistake | Replace with placeholders |
| Are logs printing config values? | Secrets may leak in logs | Remove sensitive logging |
TL;DR: The safest habit for a vibe coder is to assume every secret will leak unless it is stored outside code and kept server-side.
A lot of vibe coder security advice sounds technical, but the core principle is simple: treat every API key like a credit card number. You would not paste a credit card into a JavaScript file and hope nobody opens DevTools. API credentials deserve the same caution.
That mindset matters even more in 2026 because AI-assisted building is faster, more accessible, and more automated than ever. Speed is helpful, but it also means small mistakes spread into more files, more commits, and more deployments before anyone notices. Public reporting on incidents involving exposed Gemini keys and large-scale client-side API key exposure shows the pattern clearly: the leak often starts with convenience, not malice.
The biggest risk is exposing API keys and other secrets in places users or attackers can access—especially frontend code, public repos, screenshots, and AI prompts. Once a secret is exposed, it should be treated as compromised and rotated immediately.
Environment variables are a strong baseline, but they are not the whole story. The key also needs to stay on the server, avoid logs, avoid commits, and be rotated if exposed. For production systems, a dedicated secrets manager adds audit trails and automatic rotation.
Yes. AI tools can generate insecure patterns, copy values into files, or encourage direct client-side integrations if prompts are vague. That is why AI coding assistant security depends heavily on explicit instructions and careful review before accepting generated code.
Not necessarily. Git history, forks, clones, or earlier caches may still contain the secret. The safe response is to rotate the key immediately and then clean history using tools like git filter-repo or BFG Repo-Cleaner.
Revoke or rotate the key first—before anything else. Then move the secret into environment variables or a secrets manager, review logs and billing for unauthorized usage, and check your repo and frontend code for other exposed credentials.
.gitignore helps prevent new leaks but does not erase old commits.The defining security challenge for vibe coders in 2026 is not advanced hacking—it is accidental exposure. The builders who stay safe will not be the ones who memorize every security term. They will be the ones who adopt a few durable habits: keep secrets out of code, keep sensitive API calls on the server, scan before pushing, and assume convenience shortcuts have a cost. As AI-assisted app creation keeps accelerating, the gap between a clever prototype and a secure product will increasingly come down to whether secrets were handled correctly from day one.
Discover more content: