EMZETT.
Login

Emzett Wiki

Managing secrets: Keeping passwords and keys safe in projects

Properties1
tagsglossar, devops, sicherheit

2 min read

Managing secrets: Keeping passwords and keys safe in projects

In short: API keys, passwords and certificates do not belong in the Git repository; keep them in environment variables or secret managers and rotate them regularly.

In more detail: A secret is any information that grants access: database password, API key, token, private key. Almost daily keys are harvested from public repositories (bots scan GitHub within seconds) and used for misuse (cloud bills, data exfiltration).

In Depth

What does not work

  • Secrets in source code or in configuration files in the repo.
  • In Docker images or frontend code (every user sees it).
  • In chat, email, tickets, screenshots.
  • The same keys for development and production, for all services.
  • Permanently valid, too powerful keys.

How to do better

  1. Environment variables (.env file locally, in .gitignore), CI secrets (GitHub Actions secrets), hosting settings (Vercel, Netlify).
  2. Secret managers: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager, 1Password/Bitwarden Secrets, Doppler, SOPS (encrypted files in the repo).
  3. Least privilege: keys with minimal permissions, separate for environments and services.
  4. Rotation: renew regularly, short-lived tokens, revoke immediately on suspicion.
  5. Log and monitor access.
  6. Two access levels (no single key for everything).

Protection against leaks

  • Pre-commit hooks and scanners: gitleaks, trufflehog, GitHub secret scanning and push protection.
  • On an accidental commit: revoke/renew the key immediately (deleting from history is not enough, the data has already been copied); cleaning history afterwards (git filter-repo) only as an additional measure.
  • Check logs so that no secrets are output; do not make error messages too detailed.
  • Provide example files (.env.example) without real values.

Practice for small projects

Use .env locally and the hosting platform’s settings for production. Create separate keys per service, note them in the password manager (not in files), set budget alerts with cloud services and where possible IP restrictions or domain binding for API keys. A public browser key (for example for maps) must be restricted to your own domain.

See also: env files, Least privilege, Password manager

Backlinks