Should you commit .env files to the version control (git) repository?

Share your love

When working with Django projects, you are more likely to use GitHub or BitBucket to track and store your codebase as you write.

However, you must not commit sensitive information, such as passwords, API keys, and authorization credentials, to a publicly accessible remote repo.

Programmers, especially Django web developers, store their sensitive information in the environment variables.

So, should you commit your .env file to the git repository? You should not commit your .env files to a remote public repository as it would expose your sensitive information stored in it. Everyone who can publicly access your repository can see your API credentials, passwords, usernames, database access information, e.t.c. Thus, if you deploy your web application to the internet, people with access to such information can be able to access your website with such credentials.

What is a .env file, and how to use it in Django?

A .env file is a simple text configuration file containing key-value pairs used by your software/web application in production, local, and staging environments.

The key and value pairs are mainly used to configure your project based on the required environment variables. Instead of storing your sensitive information, such as login or API credentials, within your code, you use a .env file to store this information separately from the codebase.

Thus, the environment file is only accessible by the project/application and is usually hidden from a normal user.

Because the .env file contains important information, you should not commit the file to a remote repository, especially a publicly accessible one.

Other developers who can be able to access your repo can be able to see the information you are using in your application.

Effective ways to ensure that you have secured the sensitive information that you use in your codebase are to:

  1. Not hard code API access credentials, usernames, passwords, database connection information, e.t.c, in your codebase.
  2. Store your sensitive information in .env files
  3. Ensure that you do not expose your sensitive information in your codebase and .env files by committing them to a public repo

Ways to prevent committing .env files or other sensitive data to a remote repository

  1. Start by creating a .gitignore file before you start writing the code for your project. Add .env files and other files that you do want to commit in this file
  2. Practice adding files to git one by one after making changes
  3. Shun from hard coding sensitive data in your code
  4. Use tools such as git add --interactive to identify the changes that are to be staged. You might realize you have some sensitive data or .env file before staging the changes.

How to add .env files to .gitignore file

One effective way to ensure that you do not accidentally commit your .env file to a public repo is to create a .gitignore file and adding .env file as one of the files that should be ignored. Therefore, it acts as the first line of defense for preventing the exposure of sensitive data from reaching the public.

Here’s a step-by-step process on how to add your .env file in .gitignore

Step 1: Create a .gitignore file

Step 2: Edit .gitignore file and add the following line to the file

.env

Step 3: Save your .gitignore file, and you are good to go

What to do after accidentally committing your .env file

Sometimes, you may forget to add your .env file to your .gitignore file so that it is not pushed to the remote repository. Afterward, you realize that you have committed the file to the remote repository that is publicly available.

Here are the things that you should do to ensure that your sensitive information remains secure:

  1. Remove the .env file from the commit and remote locations
  2. Change all your API credentials and service access information

How to remove/uncommit .env file from the repository

If you have accidentally committed a .env file that contains all the secret keys, API credentials, usernames, and passwords, you should consider removing them from the git repository. Because other developers may have seen the file, removing it from the public repo is essential. Removing the .env file from a publicly accessible repo is essential because hackers or intruders cannot access the file and learn the pattern you may use for creating your passwords.

Use the commands to scrub/remove your .env file containing sensitive data from a git repository.

git rm --cached .env <ensure you specify the path to your .env file>

git commit --amend -CHEAD

git push -f

Why you should change your sensitive information after being exposed in a .env file

After realizing that you have exposed your .env file, you should consider all the usernames, passwords, and other access/authorization information. Besides, you should ensure that you change the credentials based on a pattern entirely different from the one you had used on the exposed data.

The reasons for changing your access information are

  1. Someone may have seen your file and accessed your sensitive information before you removed the .env from the repository
  2. Intruders who may have accessed your file may try to guesswork the pattern in your password that you may change to. Thus, it is important to use a totally different pattern that does not follow the obvious

In conclusion, after you realize that you have sent your sensitive information, such as passwords, API keys, usernames, database access data, license keys, e.t.c, you should consider them compromised.

The perfect solution for compromised data is to completely change them without following a pattern that is similar to the one that is compromised.

Share your love
Badi
Badi

Badi here, creator of ngangasn.com— A website dedicated to providing helpful information and how-to's of web development and hosting. Inspired by a fascination to write the most efficient code to make a computer laugh, & humans, Steve has a passion for organizing characters to create code and informative content.
What makes me happy?
Well, nothing like the feeling of finally figuring out that one pesky bug that's been driving me crazy.

Leave a Reply

Your email address will not be published. Required fields are marked *