Avoid Keeping Sensitive Info in a Code Repo: How to Remove Files From Git Version History
When using sites like GitHub in development, developers may be accidentally leaving vulnerabilities in their gits. Learn how to remove these vulnerabilities.
Join the DZone community and get the full member experience.Join For Free
One of the vulnerabilities that are really easy to exploit is when people leave super-sensitive information in source code – and you get your hands on this source code. In early prototyping, a lot of people will hardcode passwords and certificate keys in their code, and remove it later when moving to production code. Sometimes it is not even removed from production. But even in the case where you do remove it, this sensitive information can linger in your version history. What if your app is an open source app where you are sharing the code on GitHub? You probably don’t want to share your passwords.
Getting this sensitive info out of your repository is not as easy as deleting the file from the repo and adding it to the .gitignore file – because this does not touch your version history. What you need to do this is:
- Merge any remote changes into your local repo, to make sure you don’t remove the work of your team if they have committed after your own last merge/commit.
- Remove the file history for your sensitive files from your local repo using the filter-branch command:
git filter-branch –force –index-filter \ ‘git rm –cached –ignore-unmatch \ PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA‘ cat — –all
Although the command above looks somewhat scary it is not that hard to dig out – you can find in the Github doc files. When that’s done, there are only a few more things to do:
- Add the files in question to your.gitignore file.
- Force write to the repo (git push origin –force –all).
- Tell all your collaborator to clone the repo as a fresh start to avoid them merging in the sensitive files again.
Also, if you have actually pushed sensitive info to a remote repository, particularly if it is an open source publicly available one, make sure you change all passwords and certificates that were included previously – this info should be considered compromised.
Published at DZone with permission of Hakon Olsen, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.