Stop API Key Leaks: A 10-Minute Developer Setup
Secure your API keys before your next commit
A leaked API key can turn a harmless demo into unauthorized requests and unexpected charges. The fastest defense is simple: keep credentials out of client applications, source control, logs, and AI prompts. This quick-start guide covers a practical baseline you can implement in about ten minutes, plus what to do when a key escapes.
1. Keep API calls behind your backend
Never embed a secret API key in browser JavaScript, a mobile application, or a desktop binary distributed to users. Build-time environment variables do not make frontend credentials private: anything bundled into client code can be extracted.
Instead, send requests through your own backend. Your server reads the API key, calls the upstream service, and returns only the response your application needs. Authenticate users, validate request sizes, and enforce per-user rate limits. Otherwise, your backend can become an anonymous proxy that spends your balance.
2. Store credentials outside your repository
For local development, use an ignored environment file or your operating system’s credential store. A .env file is convenient, but it is not encrypted storage, and most runtimes do not load it automatically. Configure your framework or environment loader explicitly.
- Add .env and .env.* to .gitignore; allow a placeholder-only .env.example with !.env.example.
- Run git check-ignore -v .env to verify the ignore rule matches.
- Run git ls-files -- .env to check whether Git already tracks the file.
- If tracked, git rm --cached .env removes it from the index, not previous commits. Commit the removal and rotate any exposed credentials.
Use descriptive names such as FIFTYNINE_API_KEY. Avoid commands that put literal secrets into shell history, and never commit a working credential as an example.
3. Configure 59API once, on the server
59API provides low-cost, pay-as-you-go access to multiple model families, making it useful for developers testing options such as Claude Sonnet 5.5 and GPT-6.1 Sol without separate integrations. Its API base URL is https://api.59api.com; follow its integration instructions for the exact versioned path your SDK expects.
With an OpenAI SDK, load the key from your server environment and configure the base URL explicitly. For Claude Code, Codex, or Gemini CLI, use the supported credential configuration rather than pasting keys into prompts or project instructions. Keep credential-bearing configuration outside tracked files.
Verify the destination host before sending credentials. An accidental base-URL change can send your key to the wrong server. Treat any relay as an additional service handling requests: review its data-handling terms before submitting sensitive content. If affordable multi-model access suits your project, consider signing up for 59API after putting these safeguards in place.
4. Lock down deployment and CI secrets
In production, inject credentials through your hosting platform’s secret facility or a managed secrets service. Do not bake them into container images, Docker build arguments, or deployment manifests committed to Git.
- Use separate credentials for development, staging, and production wherever supported.
- Give only the required workloads and maintainers access.
- Keep secrets unavailable to untrusted pull-request jobs.
- Enable spending alerts, limits, and credential restrictions when your provider offers them.
Separate keys simplify revocation and attribution. Alerts help detect abuse, but an alert alone does not stop spending.
5. Block leaks through logs and developer tools
Redact Authorization headers, API-key headers, and credential-bearing URLs before logs leave your application. Check HTTP debug output, exception reports, tracing integrations, and support bundles—not just normal request logs.
Enable repository secret scanning and push protection where available. Add a pre-commit scanner as an extra layer, not your only defense. Inspect staged changes with git diff --cached before committing. Never paste environment dumps into issues, chat, or coding-agent conversations.
6. If a key leaks, revoke first
Assume a publicly exposed key has been copied. Revoke it immediately, issue a replacement, and update affected deployments. Check usage and billing records for unexpected activity. Then remove the secret from files, repository history, logs, and shared artifacts as appropriate.
Deleting a commit or making a repository private does not invalidate a credential. Finish by identifying the leak path and adding a specific safeguard so the next key stays private.