Secrets Management
A secret is any value that grants access or proves identity, such as passwords, API keys, tokens, private keys and connection strings. Secrets management is how you keep them out of the wrong hands.
Where secrets leak
- Source control: hard-coded values, committed
.envfiles and config files. Git history keeps them even after you delete the line. Anyone who gets the secret can use it as you: access systems and data without permission, steal or change data, run up cloud costs, and act in your name, so misuse is traced back to your account. - Logs and error messages: request headers, connection strings and full payloads written to logs. See Logging Fundamentals.
- Chat, tickets and screenshots. A key pasted into a chat channel or a bug report is visible to everyone with access, and often kept for a long time.
- Client-side code. Anything shipped to a browser or mobile app can be read by users, so a secret in front-end code is not a secret.
- AI tools. Prompts and pasted files may leave your organisation. See Confidentiality and AI.
Keeping secrets out of your code
- Ignore local files such as
.envand commit only an example with fake values (see Ignoring and Excluding Files). - Supply secrets at runtime through environment variables or, better, a dedicated secret store such as a cloud key vault or your CI/CD system’s secret storage. Environment variables are convenient but not a vault.
- Use separate secrets per environment and per service, with the least privilege that works.
- Prefer short-lived credentials and managed identities over long-lived keys where the platform supports them.
- Rotate secrets on a schedule and whenever someone with access leaves.
- Mask secrets in logs and CI output, and turn on secret scanning and push protection where available.
If a secret leaks
- Revoke or rotate it immediately. Assume it was copied.
- Check access logs for misuse.
- Remove it from the code and, if needed, from the history. This comes last, because the old value must be considered exposed anyway.
- Tell your team or security contact, and find out how it happened so the cause can be fixed.
# Bash: find commits that added or removed a string
git log --all --oneline -S "API_KEY"
# PowerShell: search files in the working tree
Get-ChildItem -Recurse -File | Select-String -Pattern "password|api[_-]?key"
Try it
In a throwaway repository, create a .env file with a fake key, commit it by mistake, then find it with the git log -S command above. Write down the steps you would take next if the key were real.
Common mistakes
- Committing a .env file or hard-coded key; Git history keeps it after you delete the line.
- Cleaning up the repository before rotating the leaked secret.
- Putting a secret in front-end code.
- Pasting keys into chat, tickets or AI prompts.
Check yourself
- You pushed an API key to a public repository. What do you do, in order?
- Why is a secret in browser code not a secret?
- Why are environment variables convenient but not a vault?