Secrets managed via environment variables or secrets manager; no credentials committed to version control

Hardcoded credentials in source code (CWE-798) or committed .env files (CWE-312) expose API keys, database passwords, and service tokens to every person with repository access — and to public GitHub if the repo is ever made public or forked. OWASP A07 (Identification and Authentication Failures) and NIST IA-5 both classify hardcoded credentials as a critical authentication control failure. PCI DSS v4.0 Req-8.6.2 explicitly prohibits hardcoded passwords/passphrases in scripts, configuration/property files, and bespoke source code. Unlike most vulnerabilities, secrets in git history persist even after the secret is removed from the current codebase — they require key rotation, not just file deletion.

Store all secrets in environment variables and exclude .env files from version control. Create .env.example as a committed template with placeholder values.

# .env.example — commit this; never commit .env
DATABASE_URL=postgres://user:pass@localhost:5432/mydb
STRIPE_SECRET_KEY=sk_test_REPLACE_ME
SENTRY_DSN=https://REPLACE_ME@sentry.io/123

Add to .gitignore:

.env
.env.local
.env.*.local

If secrets were ever committed, rotate them immediately — do not rely on git rm alone, as the values remain in history. Use git filter-repo to scrub history, then force-push. For production secret management: Vercel Dashboard → Settings → Environment Variables; AWS Systems Manager Parameter Store; or HashiCorp Vault for self-hosted.