How To Keep Secrets From Git and GitHub

And What To Do If You Accidentally Pushed an API Key to GitHub

During my time in the Web Development Fellowship at Fullstack Academy, I recently created a web application that makes use of two different external APIs: the Google Civic Information API and Propublica’s Congress API, each of which require an API key with every request. API keys are unique identifiers used to authenticate requests and they also allow the API creator to track which programs, developers, and/or users are making the requests they are receiving. In software development, an API key is considered a secret. Other examples of secrets include any authentication credential such as passwords and tokens.

My project started out as an experiment and I wasn’t really sure if it would turn into anything, so I carelessly put one of the API keys directly into one of my project files and I pushed those files to a private GitHub repository. As I spent more time on this project, I realized I wanted to continue adding more features and eventually deploy it.

As I continued working, I also decided I wanted to make the GitHub repository public so I could share the link on my LinkedIn profile and resume. At exactly this time, I also remembered a cautionary tale one of my Fullstack Academy instructors shared with my cohort. A former student had accidentally published his Amazon Web Services API key to a public GitHub repo and someone else found it and used it to rack up a huge bill with AWS. The student was eventually able to convince AWS the charges were fraudulent but it sounded like a huge nightmare and I definitely wanted to avoid a similar situation. So now I needed a way to safely store my API keys and also make sure they were not publicly exposed when I switched the repository’s settings from private to public.

One way to keep your secrets from both Git and GitHub is by using a secrets file that is set up to be untracked or ignored by git. When you start any new project that will be using external API keys, one approach is to make a secrets.js file in the root of your directory and then make sure to add it to your .gitignore file before you make any commits and/or push anything to GitHub. A .gitignore file is just a plain text file that is usually placed in the root of your directory, which can contain file names, directories or patterns that you want to exclude from Git tracking. Anything in the .gitignore file will not be pushed to GitHub.

Another way to hide your secrets from Git and GitHub is by storing them in environment variables. Environment variables are global variables in your operating system’s environment, which will be passed down to any child processes. According to Digital Ocean, environment variables are “implemented as strings that represent key value pairs.” If you would like to follow this strategy of creating environment variables to store your secrets, follow Digital Ocean’s guide on reading and setting environment variables.

A third and even more secure way to manage your application’s secrets is by using an outside service like HashiCorp’s Vault, which is a system for storing and managing access to tokens, passwords, keys and other secrets.

Okay, so what if you already accidentally pushed an API key to GitHub? Here are some steps you can take to minimize the damage.

• If you’re able to, delete the API key you published to GitHub and generate a new one. This is fairly easy to do if you’re using an API key from a larger company like Google. In your Google Developer Console, just click on credentials on the menu on the left side of your screen and you will be able to find and delete your compromised key. Once you have deleted the API key, try making a test request to the API using the old key, just to confirm that it really was deactivated. Hopefully the request fails if you have correctly disabled the key.

• If you happen to be creating a new Google API key, you can take the extra precaution of restricting it to work with only specific Google APIs, so in the unfortunate event that someone with nefarious intentions stole your API key, they would only be able to use it for very limited purposes.
• To restrict a Google API key, hover over the name of your key and click on it. You will be taken to another screen where you can add restrictions to the key.

• On the next screen, look for the API restrictions section and change the setting to restrict the key.
• Next open the dropdown menu and search for and select the APIs you want to grant access to.

This process will vary depending on the organization who granted you the API key. Google is a huge company and they have a pretty self-service and user-friendly approach to generating API keys but with smaller organizations you may have to submit a request with a reason that you need the API key and wait for a response.

So now you’ve been able to delete your old API key and create a new one that you are safely storing using one of the strategies outlined earlier. However, there’s still one last thing to consider: your Git commit history. Git is a version control system, so its whole purpose is to keep a record of all changes and versions of your project. And that history shows up in your GitHub repo, too. So if your repo is public, so is your commit history, which will show all past versions of every file in your project, including the versions where you accidentally included your secrets. If the secret was an API key and you’ve disabled or deleted it, you don’t necessarily need to edit your commit history, since the key is now useless.

However, if you want to err on the side of caution and delete the now useless API key from your git commit history as well, there are a couple of approaches you can take. The GitHub documentation has an entire section on deleting sensitive information from a repository. Some of the recommended approaches include using the git-filter branch command or the BFG Repo Cleaner, which is a widely-used open source tool. Atlassian also has a helpful guide on rewriting git history.

Keeping your secrets safely hidden away from Git and GitHub from the start of a project is always the best approach but hopefully this guide is helpful if you’ve accidentally pushed an API key or other sensitive information to GitHub.