Env & Secrets Hygiene

Secrets that leak are secrets that must be rotated — the goal is to make leaking them structurally hard, not to promise to be careful.

Never commit secrets

• .env files (or any file containing real credentials) must be in .gitignore from the very first commit of a project — added later is too late, since the secret is already in git history.
• Commit a .env.example with every variable name and a placeholder/dummy value, so the required configuration is documented without exposing real values.
• If a secret is ever committed, rotate it immediately — removing it from the latest commit does not remove it from git history; treat it as fully compromised.

Client vs. server boundary

• Never put a server-only secret (database credentials, private API keys, signing secrets) into any variable that gets bundled into client-side JavaScript — in frameworks with a public/private env variable naming convention (e.g. a specific public-prefix), double-check every prefixed variable actually is safe to expose before using that prefix.
• Assume anything shipped to the browser is public, permanently, even after you "remove" it — it may already be cached, archived, or scraped.

Access and scope

• Grant the minimum scope needed for each credential (a read-only DB user for reporting, a restricted API key scoped to only the endpoints actually used) rather than reusing one all-powerful credential everywhere.
• Use different credentials per environment (local/dev/staging/production) — a developer's local .env should never contain a production secret, and a production incident should never require sharing a production secret with a local machine to debug.

Runtime handling

• Read secrets from environment variables or a secrets manager at runtime, never hardcode them in source — this includes "just for now" hardcoding during debugging, which reliably ends up committed.
• Fail fast and loudly at startup if a required secret is missing or malformed — a service that silently falls back to a default/empty credential and fails mysteriously later is far harder to diagnose than one that refuses to start.

Logging and error handling

• Never log environment variables in bulk (e.g. dumping the full environment for debugging) — this is one of the most common accidental-leak vectors, and it's easy to leave in.
• Redact secret-shaped values (API keys, tokens, connection strings) from error messages and crash reports before they reach any external logging/monitoring service.

Rotation

• Design credentials to be rotatable without downtime where possible (support two valid keys during a rotation window) — a secret that can only be rotated by taking the service down gets rotated far less often than it should be.
• Rotate on any suspected exposure immediately, and on a routine schedule for high-value credentials regardless of suspected exposure.