DEV Community

Cover image for How to remove a leaked .env file from GitHub permanently...
Kodebae
Kodebae

Posted on

How to remove a leaked .env file from GitHub permanently...

OOoooppss...

Ok we don't have time to waste, you did the unthinkable, it was a rookie move, but we need to fix it asap! I'll skip any further banter and cut straight to the case. Here's how were gonna do it...


Quick Summary:

  • Remove .env and commit the removal.
  • Use filter-branch to delete the file from history.
  • Force push the changes.
  • Clean up the local repository.

1. Remove the .env File and Commit

  • First, remove the .env file from your repository and commit the changes:
bash
Copy code
git rm --cached .env
echo ".env" >> .gitignore
git add .gitignore
git commit -m "Remove .env file and add to .gitignore"
Enter fullscreen mode Exit fullscreen mode

2. Remove the .env File from History with filter-branch

  • Use Git’s filter-branch to remove the .env file from the entire history:
bash
Copy code
git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch .env' --prune-empty --tag-name-filter cat -- --all
Enter fullscreen mode Exit fullscreen mode

3. Force Push the Changes

  • After running the filter-branch, you'll need to force push the changes to the remote repository:
bash
Copy code
git push --force --all
git push --force --tags
Enter fullscreen mode Exit fullscreen mode

4. Clean Up Local Repository

  • Finally, clean up your local repository to remove the old references:
bash
Copy code
rm -rf .git/refs/original/
git reflog expire --expire=now --all
git gc --prune=now --aggressive
Enter fullscreen mode Exit fullscreen mode

5. Revoke Any Leaked Credentials

  • As with any method, if your .env file contained sensitive information, revoke and regenerate those credentials immediately.


πŸ˜… You did it! Hopefully nobody saw that. Pat yourself on the back and please please please don't skip step 5. You need to revoke access and regenerate new credentials to insure that you don't get hacked. You've been warned...

Ok that's it, bye!

Credits:

Author: πŸ‘©πŸ½β€πŸ’» Kodebae
Buy me a β˜•οΈ: (https://www.buymeacoffee.com/karmendurbin)
Website: (https://kodebae.github.io/kodebae-app/)
X: (https://twitter.com/karmen_durbin)

Top comments (23)

Collapse
 
ravavyr profile image
Ravavyr

It's not worth doing all that though.
Just make sure it's in the gitignore and doesn't get added anymore.
AND go and change all the credentials you accidentally leaked.

And move on. It happens :)

Collapse
 
pbnj profile image
Peter Benjamin (they/them)

Agreed with @ravavyr .

Point #5 (revoking leaked credentials) should be #1 .

The rest are optional (but recommended) steps.

Collapse
 
kodebae profile image
Kodebae

I would personally still remove the history of the leaked file from GitHub to be safe. ;)

Thread Thread
 
ravavyr profile image
Ravavyr

There is nothing wrong with doing that. It's just more effort AND if you don't do it right there will still be some branch/commit/version up there that has your old creds.

Thread Thread
 
kodebae profile image
Kodebae

This sounds opinion based and isn't the case for everyone. Depending on the level of compliance it is necessary to remove this information from your GitHub history. Its fine if you personally don't want to remove your leaked secrets, but that is simply not an option for everyone.

Thread Thread
 
ravavyr profile image
Ravavyr

Everything we do is opinion based, lol.

Thread Thread
 
bankde profile image
Bankde Eakasit

I don't think it's opinion based. More like under what the circumstances.
If it's public git, github, large team, doing the push force is just cutting your own legs.
If it's private git or small team, then why not properly clean it up and tell everyone to clean their local copy.

Thread Thread
 
kodebae profile image
Kodebae • Edited

@bankde Thanks for this input. I also think that circumstances depending could affect whether or not this is the best way to go about solving the issue. That is a good point to add. But again depending on the circumstances the purge of history may be necessary.

Thread Thread
 
ravavyr profile image
Ravavyr

because even on a small team you will end up having this discussion and spend more time arguing about it than just updating your creds and gitignore and moving on.

Thread Thread
 
kodebae profile image
Kodebae • Edited

@ravavyr I heard your opinion on the matter and I disagreed. I linked a few resources already, one from github themselves and some from other people where they all suggest a similar process to what I did. If you don't want to follow the steps I understand.

Enjoy the rest of your day.

Collapse
 
kodebae profile image
Kodebae

Please elaborate, why do you think that removing the history from the GitHub branch is not useful?

Collapse
 
ravavyr profile image
Ravavyr

because it's more effort than it's worth?
Even if you do that, you still need to clean up your credentials because they have been leaked.
So just clean up your credentials and move on.

Collapse
 
andgoedu profile image
ANDGOEDU

Great Article , If you dont mind me asking , where should i store my .env information other than github as a backup do you have a tool in mind or similar that organizes your .env files ? because from my end i just keep the .env file and make the repo private , And thank you in advance for your time for reading my question.

Collapse
 
stagfoo profile image
Alex King

I agree with @brian_rlist_c3025e6dbb I found the simplest solution is to store the file in a Keypass database and use a backup tool to backup the database and if you want to get fancy use the keypass cli to export it before build and deploy but thats optional

Collapse
 
brian_rlist_c3025e6dbb profile image
Brian R (LIST)

You may want to keep the sensitive credentials (oAuth tokens, etc.) in a password manager or similarly secure place, rather than any typical backup method

I like to create a SAMPLE.env file that contains all of the non-sensitive variables, along with comments about each variable, and a just a placeholder for any oAuth tokens or other credentials. I let this file make it into the repo by design. (Don't put *.env in the .gitignore, just .env as described in the article above to ensure SAMPLE.env is not ignored).

This gives me a backup of the entire file (minus the secrets) right in the repo, and serves as a template/quick-start for other users of the code.

Whether you are recovering from a drive loss, setting up on another computer, or another developer is using your code, you simply copy SAMPLE.env .env and update the placeholdes with the credentials.

Collapse
 
eshimischi profile image
eshimischi • Edited
Collapse
 
kodebae profile image
Kodebae

πŸ₯΄ Just going to link over to this blog post now.

I know that there is some debate going on in the comment section right now about how "unimportant" it is to remove history or rewrite the GitHub history after credentials are leaked. Yes, this is an optional thing no one is forcing you to do this. It's not something that anyone is "required" to do, but I have looked into this and having this information floating around out there can have its drawbacks. All debatable yes, so do your own research and decide for yourself.

Linking yet another resource with a quote here for those who are not 100% convinced on removing leaked secrets.

What to do after leaking credentials and API keys

"Once the secret has been revoked, it cannot be used anymore. Nonetheless, having credentials, even expired ones, could look unprofessional and raise concerns. Additionally, some secrets cannot be revoked (for example, database records), or credentials no one can guarantee were properly revoked (for example, SSH keys that can be used in many different places). While we will go through the steps of how to remove secrets from the git history, please note that this is not a trivial task, and it is advised to seek the guidance of a senior developer."

Collapse
 
nathan_tarbert profile image
Nathan Tarbert

I agree with others, that removing the leaked file from GitHub is a safe move.

Collapse
 
hitblast profile image
HitBlast

If you're planning to put tokens which can be regenerated, removing the .env file entirely from the git history is worthless. Just regenerating the credentials and adding the file to the ignored list should work wonders.

Collapse
 
kodebae profile image
Kodebae

Thanks for the comment. I linked a few resources that detail when removing the history may be necessary. This is not a one size fits all situation.

Collapse
 
kodebae profile image
Kodebae

πŸ‘‹πŸ½ Hey everyone, thanks for the comments!

I'm just now checking up on the comments here, it's been a long week.

Thank you all so much for your kind words about the article! πŸ˜„

For storing .env files securely, there are a few different options for encryption tools like EncFS for local backups or services like HashiCorp Vault for more advanced secret management. If you're looking for organization, using environment-specific .env files (like .env.development) combined with a tool like direnv could be very beneficial.

Remember to try and never commit these files to GitHub, even in private repos, and use .gitignore to exclude them. Hope this helps!

Collapse
 
mbarzda profile image
Martynas Barzda

Well, you can't delete data from Github, because Git is snapshot based VCS trufflesecurity.com/blog/anyone-ca...

Collapse
 
kodebae profile image
Kodebae

Yes GitHub is indeed snapshot based but that is why we are pruning the history in step two to rewrite the commit history. That is the entire point of this blog post. You can find more information here in the official documentation.

Removing Sensitive Data from GitHub