API Key Security Best Practices
That Actually Get Followed

This is the cardinal rule. A key committed to a git repo — even briefly, even to a private repo — should be considered compromised. GitHub's secret scanning will catch known formats immediately and send you an alert. But the key is already in git history, visible to anyone who clones or forks the repo, and indexed by tools that scan for leaked credentials.

What to do instead: use environment variables loaded from a .env file, and make sure .env is in your .gitignore from the moment you create the project. Don't add it later — add it first.

Even in code that will never be committed publicly, hardcoding an API key in source is bad practice. It makes the key visible in error logs, stack traces, and any code-sharing you might do. Environment variables keep the key out of your source entirely.

In Node.js: process.env.OPENAI_API_KEY
In Python: os.environ.get("OPENAI_API_KEY")
In shell scripts: source your .env file explicitly, never hardcode inline.

A .env file sitting on your filesystem is plaintext. If your laptop is stolen, compromised by malware, or backed up to a service with weak access controls, those keys are exposed. Encrypt your keys at rest using a dedicated tool with proper encryption.

API Locker uses AES-256-GCM with a master password that never leaves your device. No plaintext key is ever written to disk or transmitted anywhere. This is what encryption at rest actually means for developer credentials.

Most APIs let you create keys with specific permission scopes. A key used to read data from GitHub should not also have write access to your repos. A Stripe key used to display subscription info in a dashboard shouldn't have permission to issue refunds.

Why this matters: when (not if) a key leaks, a scoped key limits the blast radius. The attacker has read access to one resource, not full control over your account.

A key that has existed for 3 years has had 3 years of exposure opportunities — logs, old backups, shared environments, team members who have since left. Regular rotation limits the useful lifetime of any leaked credential.

A reasonable schedule: high-stakes keys (payment, cloud infrastructure) every 90 days. Other keys every 180–365 days. Rotate immediately after any suspected exposure or team member departure.

Many APIs support key expiry natively. Use it. A key with a hard expiry date cannot be used indefinitely after a leak — it expires on its own. The challenge is tracking expiry dates across dozens of keys.

API Locker lets you set an expiry date on any stored key and will warn you before it expires. This makes expiry-based rotation practical: you can see at a glance which keys need attention without maintaining a spreadsheet.

Most API providers offer usage dashboards and anomaly alerts. Enable them. A sudden spike in API calls from an unfamiliar IP — especially at 3am — is your earliest signal of a compromised key. Without alerts, you might only discover a breach when the bill arrives.

Also enable: GitHub's secret scanning alerts, Stripe's radar rules for unusual API patterns, and AWS CloudTrail for any API usage in your account.

Your development, staging, and production environments should each have their own API keys — never shared. This is not paranoia; it's operational hygiene. Dev keys often end up in logs, debug output, and shared code snippets. If dev and production share a key, a casual leak in development becomes a production incident.

The label discipline: in API Locker, label every key with its environment — "Stripe — Live Production", "Stripe — Test Development". This makes it impossible to accidentally copy the wrong key.