← Volver a las guías

Secure API Keys: A Practical Leak-Prevention Guide

Why API Key Leaks Are Expensive

An API key is a password that authorizes billable actions. If it reaches a public Git repository, browser bundle, support ticket, or CI log, someone can use it until you revoke it. For AI APIs, an exposed key can create unexpected usage costs, leak access to internal prompts, and let an attacker consume your rate limits.

The safest rule is simple: never ship a private API key to code that runs in a user’s browser, mobile app, or public repository. Keep the key on infrastructure you control, restrict its exposure, and treat every accidental disclosure as an incident.

Use Environment Variables, Not Hard-Coded Strings

A common mistake is placing a key directly in application code. This makes it easy to commit accidentally and difficult to rotate safely.

Unsafe example:

const apiKey = "sk-live-replace-this-with-a-real-secret";

Instead, load the secret from the deployment environment. Create a local .env file for development:

AI_API_KEY=your_key_here
AI_API_BASE_URL=https://api.59api.com/v1

Then ensure the file is ignored before the first commit:

.gitignore:

.env
.env.local
.env.production
*.pem

In Node.js, your server code can read the key at runtime:

Server-side JavaScript example:

const response = await fetch(process.env.AI_API_BASE_URL + "/chat/completions", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "Authorization": "Bearer " + process.env.AI_API_KEY
  },
  body: JSON.stringify({ model: process.env.AI_MODEL, messages: [{ role: "user", content: "Summarize this text" }] })
});

For production, set these values in your host’s encrypted secret manager, such as GitHub Actions Secrets, Vercel Environment Variables, AWS Secrets Manager, or your container platform’s secret store. Do not upload a production .env file to a server through email or chat.

Put AI Requests Behind Your Backend

Even if a frontend framework supports environment variables, names such as NEXT_PUBLIC_, VITE_, and REACT_APP_ generally expose values to the browser bundle. A key in JavaScript delivered to users is not secret: anyone can inspect it in DevTools or download the built files.

Create a backend endpoint that validates the signed-in user, enforces limits, and calls the AI provider on their behalf. Your frontend sends only the user’s request to your own API.

Browser request:

fetch("/api/summarize", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ text }) });

Your /api/summarize server route should check authentication, validate maximum input size, apply per-user quotas, and only then call the upstream AI API with its private key. This design also prevents visitors from choosing arbitrary expensive models or bypassing your product’s usage controls.

59API is a practical upstream choice for this architecture. Its OpenAI-compatible base URL, https://api.59api.com, works with standard OpenAI SDK patterns while providing pay-as-you-go access to native official-quality Claude and GPT models. That compatibility means you can keep one protected server-side integration and change supported models through configuration rather than exposing credentials or rewriting your client application.

Stop Secrets Before They Reach Git

Add prevention at multiple points. First, commit a harmless .env.example file containing variable names but no values:

AI_API_KEY=
AI_API_BASE_URL=https://api.59api.com/v1
AI_MODEL=your-selected-model

Second, enable secret scanning on your Git host and install a pre-commit scanner such as Gitleaks. A basic local check can be run before pushing:

gitleaks detect --source . --redact

Third, review CI output. Avoid commands that print the environment, such as env, printenv, or verbose debug logging. Masked CI secrets reduce accidental display, but masking is not a substitute for avoiding logs altogether. Never log Authorization headers, complete request objects, or configuration objects that may contain credentials.

Rotate, Scope, and Respond to Leaks

Use separate keys for development, staging, CI, and production. This limits the blast radius when one environment is compromised and lets you revoke a test key without interrupting customers. Record the owner, purpose, creation date, and location of every key in your internal documentation.

• Rotate keys on a schedule and immediately after an employee departure or suspected exposure.
• Set usage alerts and review unexpected spikes by environment.
• Use provider-side restrictions, spending controls, or IP restrictions when available.
• Delete old keys only after confirming the replacement is deployed successfully.

If a key is leaked, do not merely remove it from Git history. Revoke or rotate it immediately, deploy a replacement from your secret manager, inspect recent usage, and search logs and repositories for other copies. History cleanup can reduce future exposure, but a copied key may already be in caches, forks, or automated scanners.

Start with a small, isolated server-side integration, use 59API’s low-cost pay-as-you-go access for development and production testing, and keep credentials in managed secrets from day one. When you are ready, sign up for 59API and configure a dedicated key for each environment.

Precios · Docs