Manipulating secrets can be tricky, but, using your common sense, you will avoid critical issues.
👉 NOTE: Some of the following advices will seems obvious, but, hey, it’s never useless to repeat these kind of things
Never commit secrets!
Yeah, it’s obvious as f***, but by accident or ignorance, sometimes secrets are committed into git repositories… worse, into public repositories!
Note that the only acceptable exception is to commit development-scoped tokens, which are completely useless outside your local env…
Luckily, the most used services, like GitHub or Google, have robots that scans repositories, detect secrets and can warn you about those leaks, and often disable associated keys and tokens to avoid major issues.
Which leads to the next advice…
Don’t reuse tokens!
“Once exposed, a secret loses all its power.”
If your app/website/anything use another service to handle authentication, get datas or even share stuffs, you probably use tokens or API keys.
These tokens must be unique to your app and your environment (different tokens for dev and production, for instance).
If you reuse a token on different contexts, if one of these is compromise, there’s a big chance that the token will be disabled ASAP by an automatic script and/or a colleague/angry sysadmin.
And, as you may guess, every other service using the token will suffer from errors (at best) or even stop working (at worse).
Use librairies to handle secrets.
You can also let your environments keep your secrets… secret.
Most hosting/deploy solution have their ways to handle secrets, like AWS Secret Manager, GitHub Actions’ secrets, HashiCorp Vault, etc.
Everytime’s a secret leaks, a sysadmin have a stroke somewhere.
Take care of your sysadmins… take care of your secrets.
So, okay, I messed up… what can I do?
It’s not a good thing to do, but with git, you can rewrite history, to make things disappear in all your commits, as it never happens.
It’s tricky and not easy, but there’s a great tool to do it: BFG Repo-Cleaner.