Secure API Key Management: A Practical Checklist

Secure API key management means controlling how credentials are generated, stored, transmitted, scoped, rotated, and revoked so that a leaked or misused key does the smallest possible amount of damage. It's not a single tool or setting — it's a set of habits applied consistently across your codebase, your infrastructure, and your team.

If you're here because a key leaked, a scanner flagged one in your repo, or you're setting up a new project and want to do it right from the start, this article walks through the concrete practices that actually reduce risk, not just the theory.

Why API Keys Leak in the First Place

Before fixing the problem, it helps to know where keys actually escape:

• Committed to source control — hardcoded in a config file, then pushed to a public or semi-public repo.
• Logged accidentally — printed in error messages, request logs, or crash reports.
• Shared over insecure channels — pasted into Slack, email, or a shared doc.
• Bundled into client-side code — embedded in a mobile app or frontend JS bundle where anyone can extract it.
• Left in CI/CD configuration — stored as plaintext environment variables in a pipeline with broad access.

Almost every major key leak traces back to one of these five patterns. Fixing them is mostly about process, not tooling.

The Core Practices

1. Never Commit Keys to Source Control

Use environment variables or a secrets manager, and add .env and similar files to .gitignore before you write your first line of code, not after. If a key does end up in git history, rotating it is not optional — removing the commit doesn't remove the exposure, since history can be cloned before you scrub it.

# .gitignore
.env
.env.local
*.pem
config/secrets.yml

2. Scope Keys to the Minimum Necessary Access

A single key with full account privileges is a single point of failure. Where the provider supports it, create separate keys per application, per environment, and per team, each scoped to only what that consumer needs.

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "claude-sonnet-4", "messages": [{"role": "user", "content": "Hello"}]}'

If your sub_live_... key is compromised, the blast radius is limited to whatever that specific key was scoped to — not your entire Claude access. This is one reason SubToAPI issues distinct application keys per app rather than a single shared credential: you can revoke and rotate one app's key without touching the others.

3. Rotate Keys on a Schedule, Not Just After an Incident

Rotation shouldn't be a reaction to a breach — it should be routine. A practical cadence:

• Rotate production keys every 90 days.
• Rotate immediately after any team member with key access leaves.
• Rotate immediately if a key appears in a log, ticket, or chat message, even briefly.

Automate this where possible. A rotation process that requires someone to remember to do it manually will eventually get skipped.

4. Store Secrets in a Dedicated Secrets Manager

Environment variables are fine for local development, but production systems should pull keys from a secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler, or your cloud provider's equivalent) at runtime. This gives you:

• Centralized access control and audit logs
• Automatic rotation support
• No plaintext secrets sitting in deploy configs or container images

5. Never Expose Keys in Client-Side Code

If a request needs to hit an API from a browser or mobile app, the API key belongs on your server, not in the client bundle. Proxy the request through your own backend:

// Backend route — key never reaches the client
app.post('/api/chat', async (req, res) => {
  const response = await fetch('https://api.subtoapi.app/v1/messages', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.SUBTOAPI_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      model: 'claude-sonnet-4',
      messages: req.body.messages,
    }),
  });
  const data = await response.json();
  res.json(data);
});

This pattern applies regardless of which API you're calling — the frontend never sees the credential.

6. Monitor Usage and Set Alerts

A key that's being used more than expected, from an unexpected location, or at unusual hours is a signal worth investigating. Usage metadata — request counts, token consumption, error rates per key — turns anomaly detection from guesswork into something you can actually see. If you're managing multiple application keys across a team, a dashboard that shows per-key activity makes it obvious when something looks off before it becomes a real problem.

7. Revoke Fast, Without Downtime

The value of scoped, per-application keys shows up most clearly at revocation time. If one key is compromised, you should be able to kill it immediately and issue a replacement without taking down every other integration that depends on the same underlying access. Getting a new key into production and confirming the old one works before switching over — see the quickstart guide for how that flow typically looks — should take minutes, not a deployment cycle.

A Quick Checklist

• [ ] Keys are never hardcoded or committed to git
• [ ] Each application/environment has its own scoped key
• [ ] Keys live in a secrets manager, not plaintext env files in production
• [ ] Client-side code never contains a raw API key
• [ ] Rotation happens on a schedule and after any suspected exposure
• [ ] Per-key usage is monitored and alerts are configured
• [ ] Revocation and reissuing a key takes minutes, not hours

If you're building on top of Claude and want per-application keys, usage visibility, and team-level access control without building that infrastructure yourself, SubToAPI handles key issuance, streaming, and usage metadata out of the box — see pricing or the docs for details.

FAQ

What's the single most important practice for secure API key management? Never let a key have more access than the specific consumer needs. Scoping limits damage far more effectively than any monitoring or rotation policy applied after the fact.

How often should API keys be rotated? A reasonable baseline is every 90 days for production keys, plus immediate rotation after any suspected exposure or when someone with access leaves the team.

Is it safe to put an API key in a mobile app or frontend JavaScript? No. Anyone can extract strings from a compiled app or JS bundle. Route the request through your own backend so the key only ever lives server-side.