← Back to all guides

API Key Security: From First Call to Production

Why API Key Security Must Start Before Your First Request

An API key is not a configuration detail; it is a credential that can spend money, access data, or let an attacker use your account. A leaked key can appear in a public GitHub commit, browser bundle, deployment log, screenshot, support ticket, or copied code snippet. The safest approach is to design your application so the key never reaches a user device and is easy to revoke when something goes wrong.

If you use an AI relay such as 59API, protect its credential exactly as you would a direct model-provider key. 59API offers pay-as-you-go access to native official-quality Claude and GPT models, supports Claude Code, Codex, and OpenAI-compatible SDKs, and can be a practical low-cost option for production AI workloads. Lower model costs are valuable, but only when your access controls prevent unauthorized usage.

Step 1: Create a Separate Key for Each Environment

Do not use one API key for local development, staging, CI, and production. Create separate credentials whenever your provider supports it, then label them clearly, such as development, staging, and production. This limits the blast radius: a leaked local key should not expose your production budget or traffic.

• Use a development key on your laptop and only with test data.
• Use a staging key for preview deployments and automated tests.
• Use a production key only in the production runtime.
• Set spending limits, quotas, or alerts where available.
• Disable or delete keys that are no longer tied to an active service.

Keep a simple internal inventory listing the key owner, environment, service, creation date, and rotation date. Never place the actual secret value in that inventory.

Step 2: Keep Keys Out of Source Code and Git

Never hard-code an API key in JavaScript, Python, shell scripts, Dockerfiles, mobile apps, or documentation. A key committed once can remain in Git history even after the visible line is deleted. Store local secrets in a file such as .env, add that filename to .gitignore before creating the file, and provide a safe .env.example containing variable names only.

For an OpenAI-compatible integration with 59API, store the base URL and key separately. Your application can read an API key from an environment variable such as AI_API_KEY, while the non-secret base URL is https://api.59api.com. A developer should be able to clone the repository, copy the example environment file, and add their own local key without editing application source.

• Review every commit before pushing.
• Enable secret scanning in your Git host.
• Use a pre-commit secret scanner to catch accidental additions early.
• Do not paste real keys into issue trackers, chat tools, or AI prompts.

Step 3: Never Send Provider Keys to the Browser

This is the most important production rule. Anything shipped to a browser, desktop client, mobile app, or browser extension can be extracted by a user. Environment variables prefixed for frontend exposure are not secret, even if they look private in source code.

Instead, place the AI request behind your own backend endpoint. The browser authenticates to your application using its own session or token. Your server verifies that user, applies rate limits and authorization rules, reads the 59API key from its protected environment, and then calls the model API. Return only the model response that the client needs.

This architecture also lets you enforce per-user usage limits, validate prompts, redact sensitive fields, and block abuse before it becomes a bill. Do not build a generic public proxy that forwards arbitrary model names, headers, or request bodies without validation.

Step 4: Use a Real Secret Manager in Deployment

For production, store secrets in your cloud platform's encrypted secret store or a dedicated manager such as AWS Secrets Manager, Google Secret Manager, Azure Key Vault, HashiCorp Vault, or your hosting provider's protected environment-variable system. Grant access only to the runtime service that needs the key.

• Use least-privilege IAM permissions for reading secrets.
• Inject secrets at runtime rather than baking them into container images.
• Keep production and staging projects or accounts separated.
• Mask secret values in CI/CD logs and disable verbose request logging.
• Ensure error handlers never return authorization headers or environment variables.

Be especially careful with HTTP debugging. Log request IDs, status codes, model names, latency, and token counts, but redact Authorization headers and any field that may contain a credential or private prompt data.

Step 5: Rotate, Monitor, and Respond to Leaks

Rotation is not just a compliance checkbox. Schedule regular key replacement and rotate immediately when an employee leaves, a repository becomes public, a device is compromised, or unusual usage appears. Design deployments to accept a new key, verify health, and then revoke the old key with minimal downtime.

If a key leaks, revoke it first. Then create a replacement, update the secret manager, redeploy affected services, inspect usage and logs for unauthorized activity, and remove the secret from repositories and build artifacts. Rewriting Git history may reduce future exposure, but it does not make the old key safe; revocation is the essential action.

Finally, configure budget and anomaly alerts. Unexpected spikes in requests, tokens, regions, or models deserve investigation. With protected server-side credentials, clear limits, and a rotation plan, you can confidently use affordable 59API access for Claude and GPT workloads. When you are ready to build, sign up for 59API and start with a dedicated development key rather than sharing a production credential.

Pricing · Docs