Chapter 1 of 7 · 5 practices · 4 min · 4-question quiz
Where secrets should live
The right home for a secret depends on the size of your team and setup, but there are a few places a secret should never be.
Start: Never commit secrets to git, even in private repositories5 practices in this chapter
- 1Never commit secrets to git, even in private repositoriesGit keeps every version of every file forever, and repositories get cloned, forked, made public and copied to laptops. A secret committed once should be treated as exposed, even if you delete it in…
- 2Use a secrets manager once more than one person or service needs a secretOnce more than one person or service needs a secret, ad hoc sharing stops working. OWASP recommends centralizing secrets in one system with consistent rules for who can access them, plus an audit…
- 3Inject secrets at runtime instead of baking them into buildsEnvironment variables are a fine way to hand a secret to a process, as long as the value is supplied when the app starts, not compiled into an artifact. Secrets inside a Docker image, a mobile app…
- 4Use different secrets for development, staging and productionIf your laptop's
.envholds the production database password, every laptop is a production risk. A stolen or shared laptop, a debugging session on a coffee shop network, or a stray copy in a backup… - 5Keep an inventory of every secret, its owner and where it is usedDuring an incident, the slowest part is often working out what a leaked key is for, who owns it and what breaks when you revoke it. OWASP recommends documentation that lets you find and understand…
Check yourself on this chapter
4 questions, right here once you are signed in. Your progress is saved as you read.