Security
Secrets
Sensitive credentials — API keys, tokens, database passwords, private keys — that grant access and must never land in source control, logs or client code. Leaked secrets are one of the top causes of breaches. Keep them in a secrets manager or injected env, scan repositories with tools like gitleaks, and rotate immediately on any exposure.
Purpose
Secrets are the credentials that grant access — API keys, tokens, database passwords, signing keys. Unlike code, they must never be shared, versioned publicly or logged; a leaked secret is a standing invitation until rotated, and leaked secrets are one of the most common breach origins.
When to Use It
Every integration involves them: your app's database password, third-party API keys, JWT signing keys, deploy credentials in CI. The discipline applies at every scale — a solo project's .env committed to a public repo is a compromise within hours; scanners crawl GitHub continuously.
Trade-offs
Perfect hygiene has friction — vaults, rotation, injection — which is why shortcuts (hardcoding, sharing in chat) persist. The asymmetry decides it: the cost of hygiene is minutes; the cost of a leaked cloud key can be a five-figure bill or a full breach before you wake up.
Implementation
Keep secrets out of git entirely: environment injection locally (.env in .gitignore), a secrets manager in production, the CI platform's secret store for pipelines. Scan repos and history with gitleaks/trufflehog, grant least privilege per credential so leaks have small blast radius, and on any exposure: rotate first, investigate second — git history rewrites do not un-leak anything.