Protect your environment variables at all cost

What is the problem being solved?
The problem being solved is the accidental exposure of API keys, passwords or other sensitive data being exposed accidentally in a git repo

Who is this for?
Beginners working with Git/Node.

Speaking with a fellow dev recently, it was mentioned how he was updating an old github project and had accidentally pushed his AWS keys to github after adding the credentials.yml file to the project level .gitignore (hint, your git cache needs to be cleared if you add a file to the .gitignore file of an already tracked repo).

Within 4 hours a notification email from Amazon had came that his account had been comprised, accompanied by the appropriate mitigation steps (change password, 2FA, check unauthorized instances and shut them down manually).

Looking through his AWS account the next morning he found 20 EC2 instances had been started in every single region, US, EU, South Korea you name it. Data transfer usage billed in less than 24 hours sat at ~$10,000 with a projected monthly usage much much higher.

A quick search on Google resulted in several Quora answers with similar results of being comprised and that Amazon was crediting back for the unauthorized usage, some with data transfer bills as high as $250,000.

This is what inspired this article on the best practices to protect one of the most important aspects of a project, your environment variables. My hope is that you will implement these strategies and protect yourself or your employer from a security breach.

Environment Variables

API keys should avoid being hard coded in code at all costs as these values could easily be uploaded to a shared git repository by accident, giving unvetted access to your account with the API provider.

Environment variables can be managed in a separate .env/credentials file locally in the project, stored in your system variables on your machine and secured in production on the server as an environment variable.

This allows the credential file to be added to a local .gitignore or a global .gitignore to prevent accidental upload.

The following steps are what I recommend to help secure you and your teams credentials.

Global .gitignore

Project .gitignore files are well known, but the lesser known more important .gitignore file can be setup on your machine and apply to every git repository you track.

To setup, open the terminal and type:

$ git config --global core.excludesfile ~/.gitignore_global

Now you can add any files or extensions you want to make sure don't make it to a git repository.

You can open the file from the command line with:

$ vim ~/.gitignore_global

Once inside vim editor hit i to insert text and :q to save/exit when finished

Some common entries that would be used for credentials include .env variables.env credentials.yml /node_modules depending on your project/coding language.

An extensive list of recommend file extensions can be found here:
https://gist.github.com/octocat/9257657

Local project .gitignore

This is the most common type of .gitignore and can be found in the git project root directory.

This file is simply created after running git init

Any file extensions, files or folders listed in this file will be ignored from git tracking.

https://git-scm.com/docs/gitignore

Clearing the git cache

If you have already initialized your git repo and want to add files to your .gitignore after having already tracked files you will need to clear the git cache using:

$ git rm -r --cached .
$ git add .`
$ git commit -m "new files added to .gitignore not being tracked"

If you forget to clear the cache and add a file you don't want tracked to the gitignore and do a normal git add . git commit -m "file will be added to git" your file will be pushed to git unless you have setup the global .gitignore with the proper extension.

Clearing Your Mistakes With BFG

If you do happen to expose an API key by mistake, all hope is not lost. Make sure to cancel and rotate the key so no damage can be done. You can also remove text/folders from a git repo easily using BFG

https://rtyley.github.io/bfg-repo-cleaner/

Install on Mac:

$ brew install bfg

Now you can remove text from your git commit history using:

$ bfg --replace-text variables_file.env
$ git add .
$ git commit -m 'text removed'
$ git push --force

This will insert REMOVED for text of this file like so:

Please read the instructions printed for BFG as this won't delete the file you will have to do that manually, this will only remove the text from your commit history.

You can also remove the entire file/folder
$ bfg --delete-folders .git --delete-files .git --no-blob-protection my-repo.git

Dotenv (.env)

All this talk on how to protect your API keys, but how do actually prevent hard coding your keys?

Simple, using an NPM package called dotenv

Install with:

# with npm 
$ npm install dotenv

# or with Yarn 
$ yarn add dotenv

Now in your application, typically at the top of the server.js file use:

$ require('dotenv').config()

Create a .env file in the root of your project structured as:

API_KEY=3nds234nds2

Now you have access to the key using process.env.API_KEY which will be converted to your key value when your code is built. Any commit to git will see proccess.env.API_KEY rather than your actual key value.

Now you can sleep at night knowing your keys are protected!