What to do if I accidentally commit an API key or other sensitive information to the git repo?
from mypasswordis1234@lemmy.world to programming@programming.dev on 18 Aug 2024 02:36
https://lemmy.world/post/18775358
from mypasswordis1234@lemmy.world to programming@programming.dev on 18 Aug 2024 02:36
https://lemmy.world/post/18775358
I know that pushing a commit with an API key is something for which a developer should have his balls cut off, but…
…I’m wondering what I should do if, somehow, I accidentally commit an API key or other sensitive information, an environment variable to the repo.
Should I just revoke the access and leave it as is, or maybe locally remove this commit and force-push a new one without the key? How do you guys handle this situation in a professional environment?
threaded - newest
Rotate the keys, the old one is on the Internet forever
This is the only answer. Git history is forever.
you can overwrite it
If you upload anything to the internet unencrypted, it’s always best to assume it’ll be publicly accessible forever.
Another user shared this link. trufflesecurity.com/…/anyone-can-access-deleted-a…
s/git/github please
If it’s a publicly-accessible repo, then immediately revoke the key and leave it. Force-pushing isn’t good enough because the old commit will still be tracked by Git until the garbage collector kicks in, and you don’t have control over the GC on GitHub (not sure about other providers).
If it’s an internal repo that’s only accessible by employees, then you probably should still revoke it, but you’ve got more leeway. Usually I’d create a ticket to revoke it when there’s time, unless this is particularly sensitive.
rtyley.github.io/bfg-repo-cleaner/
Also revoke the key of course
Revoke, invalidate, rotate, blacklist, do whatever to make the key/information not usable for that system anymore. It’s an “exploit” (but more a defining feature of git) to record everything because each link is dependent on the last thing and even old branches can be brought back and searched through.
Other answers have only called out rotating the secret which is how you fix this specific failure. After you’ve rotated, delete the key from the repo because secrets don’t belong in repos. Next look at something like git-secrets or gitleaks to use as a local pre-commit hook to help prevent future failures. You’re human and you’re going to make mistakes; plan for them.
Another good habit to be in is to only access secrets from environment variables. I personally use direnv whose configuration file is globally ignored via the core.excludesfile.
You can add other strategies for good defense-in-depth such as a pre-receive hook checking for secrets to ensure no one can push them (eg they didn’t install hooks).
The smoking man clearly has engineered with humans before. Kudos for excellent advice.
I kind of think this is a bad idea because environment variables can be read from anywhere and aren’t designed to be secret.
But I’m not sure what a better solution is tbh.
Sops, or OpenBao
Storing them in files with correct permissions.
also storing them outside of the webserver directory
you’re not entirely wrong, but this is the current standard/accepted advice for local development - probably what we’re talking about given this thread is about git commits - because the chance of exploit via this mechanism requires local access… with such access, you’re pretty screwed in far more ways
You don’t say if you noticed before pushing. If it’s your last commit and not pushed yet, you can still amend your last commit.
howtorotate.com
If it’s a public repo, revoke the key (on your own/company repo it might not matter so much)
Then
git reset head~1git push - fIf you pushed to github, that key is there forever! (very few exceptions). Regardless, if you pushed it to any machine you don’t own, assume it’s compromised and rotate.
Anti Commercial-AI license
As others have already pointed out, you must rotate the key. I don’t even put any restrictions on that. Once you have shared a secret in any way, it is no longer a secret. Don’t try to avoid work, just because it is an inconvenience. Convenience is the enemy of security.
Rotating your key is not enough though. Verify that it wasn’t used. API providers also often provide audit logs to show when credentials were used and from which location. If someone had your key only for a second, they could have used it to generate a new key you don’t even know about. Audit!
If you didn’t push your changes yet, you can use
git filter-branchto remove it from all your commits. If you already pushed (or figured out that someone committed and pushed a key), you can do the same with force-push, but also revoke the key.