Secrets Management

TL;DR: Secrets do not belong in code. Use environment variables locally, a secrets manager in production, and never let them touch version control.

Hardcoded secrets in source code are one of the most common causes of real-world breaches. It happens more than you’d think, a developer commits a key “temporarily,” it gets merged, and three months later it’s in the git history of a public repo.

Git history is permanent. Even if you delete the secret from the current file, it still lives in every commit that came before.

The rule is simple: secrets go in environment variables, not in code.

For local development, use a .env file and add it to .gitignore immediately, before you put anything in it. For production, use a dedicated secrets manager like AWS Secrets Manager, HashiCorp Vault, or your platform’s equivalent. These give you rotation, audit logs, and fine-grained access control.

const apiKey = process.env.API_KEY;
if (!apiKey) {
  throw new Error('API Key not set in environment variables');
}

Also worth doing: rotate your secrets regularly. If a key was exposed without you knowing, rotation limits how long the damage window stays open.

Further reading: 12 Factor App, Config section