← Back to all guides

API Key Security: A Practical Leak Prevention Guide

Secure API Keys Before They Become an Incident

API keys are credentials, not configuration details. Anyone who obtains a valid key may be able to make requests, consume your budget, access sensitive data, or impersonate your application. The right protection level depends on where the key runs, what it can access, and how expensive abuse would be. This guide helps you choose practical controls for local development, source control, CI/CD, client applications, and production services.

First Decision: Can the Key Be Exposed to a User Device?

If code runs in a browser, mobile app, desktop client, browser extension, or public repository, assume users can inspect it. Do not embed a privileged API key in frontend JavaScript, mobile binaries, public configuration files, or downloadable examples. Obfuscation is not protection: attackers can inspect network requests, application memory, source maps, and bundled assets.

Instead, place the key on a server you control. Your client should authenticate to your backend, and your backend should call the external API. This also lets you enforce user-level quotas, validate requests, redact sensitive input, and stop abuse without replacing every installed client.

For AI workloads, a relay such as 59API can simplify this server-side pattern. Its base URL is https://api.59api.com, and its compatibility with OpenAI SDKs, Claude Code, and Codex means you can usually change endpoint and credential configuration without rewriting your application. Using native official-quality Claude and GPT models through a low-cost, pay-as-you-go relay can also make server-side budget controls more practical.

Second Decision: Where Should the Secret Live?

For local development, use environment variables loaded from a local file that is excluded from Git. A common approach is a .env file containing values such as API_KEY=..., paired with a committed .env.example that contains placeholders only. Confirm that .env, local credential files, build artifacts, and editor backups are listed in .gitignore.

For deployed services, store keys in your cloud provider's secret manager, deployment platform secret store, or a dedicated vault. Inject the secret as an environment variable at runtime. Do not place it in Dockerfiles, container images, Terraform variables committed to source control, application logs, or static deployment manifests. Restrict read access to the service identity that actually needs the secret.

Third Decision: How Much Authority Does This Key Need?

Use separate keys for local development, staging, CI, and production. Separate keys limit the blast radius: a leaked development key should not charge a production account or affect customer traffic. Where your provider supports it, configure spending limits, rate limits, allowed origins or IP addresses, endpoint scopes, expiration dates, and project-level isolation.

For a shared service, do not give every engineer one production key. Grant access through your secret manager and audit who can retrieve it. For CI/CD, create a dedicated key with the narrowest practical permissions and expose it only to trusted branches and protected environments. Pull requests from forks should never receive production secrets.

Detection and Response Matter as Much as Prevention

Enable usage alerts before you need them. Watch for sudden token consumption, requests from unexpected regions, unusual error spikes, or traffic outside normal deployment windows. Record request metadata carefully, but never log authorization headers, raw API keys, or complete sensitive prompts. Redact secrets at the logging layer, and check error-reporting tools because they can capture environment variables and request headers.

Treat a suspected leak as active until proven otherwise. Immediately revoke or rotate the exposed key, deploy the replacement through your secret store, review usage and logs, and identify the exposure path. Removing a key from a Git commit does not make it safe; Git history, forks, caches, build logs, and package registries may still contain it. Rotate first, then remove historical copies and add automated secret scanning.

Simple API Key Security Checklist

• Keep keys out of browser code, mobile apps, public repositories, and screenshots.
• Use environment variables locally and a managed secret store in deployed environments.
• Commit placeholder configuration only; verify local secret files are ignored by Git.
• Use different keys for development, CI, staging, and production.
• Apply rate, budget, scope, origin, IP, or expiry restrictions where available.
• Never log authorization headers, raw keys, or secret-bearing environment variables.
• Enable usage alerts and review unexpected consumption promptly.
• Rotate any exposed key immediately, even if the repository was made private.

Security should not force you to overpay for dependable AI access. 59API offers a cost-conscious, pay-as-you-go route to Claude models, including Opus, Sonnet, Haiku, and Fable, plus GPT models, while preserving familiar SDK workflows. When you are ready to keep credentials server-side and separate environments cleanly, sign up for 59API and create distinct keys for each environment.