guides · 2026-10-11
Secret Hygiene: Stop API Key Leaks
Every leaked API key has the same epitaph: "it was only temporary." Keys pasted into client-side code, committed to git, dropped into AI chat prompts — each one is a credential that now belongs to everyone. Here's where secrets actually escape, and the hygiene habits that keep them contained.
Where secrets leak
1. Client-side code
The number-one leak vector. const STRIPE_KEY = "sk_live_..." in a JavaScript bundle isn't a secret — it's a string anyone can read with View Source. Frontend code can only safely hold publishable keys (designed to be public, like Stripe's pk_ keys); anything with sk_, "secret", "private" or "admin" in the name belongs on a server.
2. Git history
Committing a key and then deleting it in the next commit doesn't help — it's in the history forever, and secret-scanning bots watch public repos in real time. AWS, GitHub and Stripe all run scanners that revoke or alert on keys found in public commits, sometimes within minutes. Private repos aren't safe either: every clone is a copy, every ex-employee a risk.
3. AI chat prompts and generated code
Pasting production code into an AI assistant to "fix this auth bug" sends your secrets to a third party. Many AI tools train on or retain conversations; some have suffered prompt-data exposures. Treat AI chat like a public forum: sanitize before you paste. And review AI-generated code for hardcoded placeholder keys the model "helpfully" filled in — developers have shipped sk-test-123-style keys that turned out to be real keys from training data.
4. Logs, error messages and URLs
Keys end up in log files (logged request bodies), error trackers (stack traces with env dumps), and URLs (query parameters in access logs and browser history). Log the key's prefix for debugging, never the key.
5. CI/CD and chatops
Secrets in CI config files, echoed in build logs, or pasted into Slack "just for a sec" — each is a leak with an audience. CI secrets belong in the platform's secret store, masked in logs, with minimal scope.
The rotation runbook
When a key leaks — assume it has, the moment it touched anywhere public — rotate immediately:
- Generate the new key first in the provider's dashboard.
- Deploy the new key to every service that uses it.
- Revoke the old key — only after the new one is live everywhere, to avoid downtime.
- Check for abuse: review the provider's usage logs for the exposure window. Unexpected spikes mean someone found it.
- Remove the leaked value from code, history (rotate + purge, or accept history is burned), chats and logs.
Speed matters more than elegance. Most providers make rotation a three-click operation — the bottleneck is always human hesitation.
Building leak-proof habits
- Environment variables for everything: no secret ever lives in source code. Use
.envfiles locally (gitignored from day one) and a secret manager in production. - Pre-commit scanning: tools like gitleaks or trufflehog catch keys before they reach the repo. Make them blocking, not advisory.
- Least-privilege keys: scope every key to the minimum permissions it needs. A read-only analytics key that leaks is an embarrassment; a full-admin key that leaks is an incident.
- Separate keys per environment: development, staging and production get different keys, so a leaked dev key can't touch production.
- Expiry and rotation schedules: keys that rotate every 90 days limit the blast radius of silent leaks.
- Sanitize before AI: strip secrets from any code you paste into AI tools — or better, use tools that scan your snippets first.
Scanning is the safety net
Habits fail; automation doesn't get tired. Vibe-Code Audit scans pasted code and live sites for 32 secret patterns (AWS, GitHub, Stripe, OpenAI, Supabase, Twilio, private keys, JWTs and more), shows each leak's blast radius, and Pro adds the exact rotation runbook for the key type found. Run it on every AI-generated change before merge — it's the cheapest incident you'll ever prevent.
Informational explainer, not a security guarantee. Scan your code free before every deploy.