APIs, API keys, Environment Variables, and Security


Most web applications that are currently being built or already exist usually rely on at least one 3rd party API if not dozens. A 3rd party API is something that a web application uses to gain access to another web application’s and / or company’s services. For the remainder of this post an ‘API’ will be assumed to be a 3rd party API. This means it belongs to another web application and / or company and not the web application using the API.

Here are a couple examples of common APIs: Google Maps JavaScript API, Facebook Graph API, Twitter API.

These APIs serve as bridges to connect a given web application to a respective service that Facebook or Google or Twitter (among others) provides and controls. Data travels back and forth on these bridges between a given web application and a respective service. In some cases these services will incur costs for the web application using them. There are also certain situations where using an API to gain access to a service may be completely free as long as the usage of the API is within a certain quota that the company providing the service defines.

To gain access to these APIs some APIs require you to only use an API key and others may require you to use API key, API ID, API token, or some other identifier. The amount of fields that an API chooses to use to authenticate other web applications with their services is up to the API provider. In most cases it’s usually API ID and API key, sort of like email and password when users need to authenticate with basic web applications, like email or social media platforms.

A common question that is asked is what is the most professional and secure way to store API credentials (ID’s, keys, tokens, hashes, etc.)

There have been many discussions throughout the years about best practices on how to store API credentials. Most professional web application developers agree that storing API credentials in the database or in the code or code repository is a security issue (and generally speaking, a no-no). Many professional web application developers agree that storing API credentials at the OS level is preferable and is one of the more secure ways to do it. The rest of this post will walk you through how to store API credentials on a production level Linux / UNIX OS box using environment variables.

Technical: This part assumes that your production deployment OS is Linux / UNIX based and that you have administrative access to the user accounts and files associated with deployment of the web application you will be working with (a little knowledge of the terminal is also required).

What follows is an example of how to update your .bashrc file to account for the environment variables you’re going to add to enable access to 3rd party APIs:

Bash Terminal Guide:

Open the .bashrc file of the user in the OS that is associated with the deployment of the web app

vim ~/.bashrc

Add the following to the bottom of the .bashrc file (be sure to repeat for as many API credentials as you need)

export SOME_API_ID = "api_id" # make sure to include the quotes
export SOME_API_KEY = "top_secret_api_key" # make sure to include the quotes

After entering all of your API credentials as environment variables in the .bashrc file, save it and exit the text editor. From the terminal prompt, run the following to register the new environment variables in the OS

source ~/.bashrc

if everything has gone correctly then executing


Should yield:

api_id: command not found

Which is the value we stored in the .bashrc file (similar results should happen when referencing $SOME_API_KEY)

Next is an example of accessing environment variables in a Ruby (and by extension Ruby on Rails) environment:

# Ruby on Rails console Example
$ 2.2.3 :001 > ENV['SOME_API_ID']
=> "api_id"
$ 2.2.3 :002 > ENV[‘SOME_API_KEY’’]
=> "top_secret_api_key"

In different web application frameworks the OS environment variables are accessed differently, but with Ruby on Rails it’s as easy as writing “ENV[‘SOME_API_ID’]” anywhere in the codebase that this code can be executed.

Fun Fact: Type “env” into the terminal prompt to see a list of existing environment variables.

2 Comment

  1. Carl P. Corliss says:

    It should be noted that this is really no less secure than storing the password in your code. A crafty enough attacker could just as easily look at your environment (via /proc//environ) as look at your code.

  2. Sergei Mellow says:

    Google’s view on security, this post didn’t cover all of their best practices, like IP restrictions.

    We didn’t dive too deep on additional ways to secure the use on an API key. Having an API key be valid for only a for specific IP address is another pretty good security layer to add.

    “Well if the machine is compromised, all bets are off anyway.” – bxclnt from Reddit.

    When you suggest storing API credentials in environment variables is no less secure than storing them in the code I assume that you mean they are in “.gitignore” and in the source tree. That approach is similar to storing API credentials in environment variables. The only difference is the API credentials are being stored in the source tree which directly connects these API credentials to the source tree.

    If you want more security for stored API credentials on your deployment machine you could use HSM or TPM to store the API credentials in an encrypted manner that you can retrieve programmatically or you can also store API credentials on an encrypted disk with the account credentials for the service or application that uses it.

    We appreciate the feedback, we would love to learn other secure ways and best practices of storing API credentials.

Comments are closed.