Don’t Commit Your API Keys to Git with this Simple Technique

Tony Mackay

Sep 28, 2020·3 min read

I’m sure you’ve read the stories of people that accidentally committed their AWS keys to a public Git repo and how costly this mistake can be.

Some random script kiddy scans GitHub for projects that contain API keys, steals the key and uses it to deploy instances that mine cryptocurrency, running up huge bills.

Ouch!

This problem can be avoided with this simple technique.

Store Config in the Environment

First of all, don’t store the API key or any other configuration information in your code. This is rule number three of creating Twelve Factor Apps which I encourage you to read about here.

If you’re following the Twelve Factor Apps guidelines, you should be loading the API key from an environment variable like shown in the following Go code:

How to Inject the API Key

Now how do you inject the API key?

If you run the sample program above, the key variable will be empty (see output in the terminal window of the screenshot below).

This is because you need to assign the API key to the environment variable before running the program like so:

export API_KEY=mykey
go run main.go

Make It Easier to Run the Program in Dev

It would be a pain having to type export API_KEY=mykey each time you want to test the program, especially if you have lots of config options to set. One potential solution, is to create a file then use the source command to load it.

For example, create a file called myapp outside your repo, I suggest putting it in a folder called ~/.secrets

mkdir ~/.secrets
touch ~/.secrets/myapp

Open the file ~/.secrets/myapp and add with the following contents:

export MY_API_KEY=mykey
export MY_CONFIG_OPTION=moreoptions

Now run the source command before running the program.

source ~/.secrets/myapp
go run main.go

The API key is now accessible from inside the program, as you can see in the demo screenshot below:

If you find typing the source command each time a pain, you can create a bash script and store it in your repository. For example, create a script called run.sh with the following contents:

#!/bin/bash
source ~/.secrets/myapp
go run main.go

Since the source command is loading the file containing your secrets from a location outside the repo, it’s safe to commit this bash script to your Git repository. Now you can run it with a simple.

./run.sh

Conclusion

This is a simple method I’ve been using to keep API keys and secrets outside my public Git repositories. I don’t use .env files because they can accidentally get committed. I’m sure there are better ways than this, and if you know any, let me know by leaving a comment.