Strategy for Keeping API Keys Out of Source Control

To summarize:

• You have an API key issued to you by a vendor so you can use their API, and you have an obligation to prevent this key from being known by anyone else
• You are making calls to that vendor's API (which require the API key) in your application code
• You are deploying the application to systems where customers have access to the binaries and thus could potentially decompile/deobfuscate the code or intercept traffic

The best way to prevent compromise of this key is to keep control of it. This means it should never be deployed on a server where anyone besides you could read the binary, and never go over a communication link you don't control.

Ultimately, if the binaries are out of your control, everything in them is out of your control. Likewise, if someone can intercept traffic, they can capture the API key (potentially even if you're using SSL).

I can see two primary ways to accomplish this, both of which don't include your private API key in your deployed application:

Get a unique API key for each deployment

This would require some additional relationship with the vendor, where you can obtain keys or have your customers obtain keys.

This is actually quite common with, for example, products that use Google Maps API. The creator of the software has their own key they use while developing/running their copy, but they do not include it in the software, and instead, require you, as the user installing said software, to go to Google and obtain your own API key. The software merely has a configuration option to set the Google Maps API key to use.

In fact, many vendors that issue API keys contractually require you do things this way, so you may even be off on the wrong path anyway, and this may be the only solution you're allowed to use according to the vendor's Terms of Service and/or any legal contracts you may have with them.

Use a Proxy

Set up a proxy API, where your application calls your API (on your servers), and in turn, your API calls the vendor's API using the key.

You may need additional protection on your API, eg, something to ensure only your application is using it. This could be done by:

• making the functionality so specific nothing but your app can use it
• IP whitelists
• Some existing licensing/authorization mechanism you already have for your servers
• Your own API key system where you can issue keys to your customers

The thing to keep in mind here is that you may not be allowed to do this. Your vendor may have Terms of Service or legal contracts that prevent you from building an "aggregation service" or proxy, so you need to check with that.

Handling Misbehaviour

Even if your key doesn't get compromised, if one of your customers is doing something that causes the vendor to block your key, suddenly ALL your customers are disabled, and your only fix is to update everybody else.

Similarly, if you want to block one of your customers (eg, they stopped paying, have pirated the software, etc) then you can't do it without issuing an update to everybody else, and then disabling the key.

The logistics of this for anything beyond a handful of clients will quickly becoming untenable.

Whether you act as a proxy or have a unique key for each installation, you can handle any of these situations relatively easily (and with little to no impact to anyone else).

Trying to protect the key while it's embedded in your software is ultimately a futile effort. No matter what you do, any attacker that has access to the binaries, source, and/or communications channel and is determined enough to get at they key will be able to do so.

So don't embed it. "The only winning move is not to play."

No it should not.

A key has different specifications to source code or program.

The product should not work without a key
It is specification of product that it does not work without a key. If you include the key in the distribution you effectively destroy its use.

A key should be easily replaceable.
In fact, sometimes it's needed to regularly replace it. And sometimes a deploy of a new version is a difficult and long process. Combine that with the need to rebuild your project to get a new key, and you have the recipe for a perpetual headache. If you do not require a rebuild to get the new key, then there is no reason to put the key into git - it's not used in building, bundling or testing your app.

Consider code audits.
An auditor needs to have access to source code to verify logic (and sometimes to a working program). They are not supposed to see (and hence be able to memorize) your private keys. I'm not going to go through whether it's realistic to memorize a 2048-bit key by glancing at it - sometimes reviews are done remotely.

A key does not need a history.
A key is not tied to the version of the software in most cases. Key change dates and reasons may be interesting, but those do not need to be available to everyone.

Keys are issued per company or per server, not per application.
Should you ever decide that you need a second server in another country with different laws and a different key, or allow a different company to run your server software as well, this is most important. Those should have different keys. Bundling your key with the app is a no-go then.

Keys should not be public information
Does your intern really need to have access to your production server key? Really? Does your compliance/security department concur?

There is but one key that you may want to include in Git - a test key for an internal test server or a local server. That will ease initial deployment and allow you to change key formats without making a company wide email asking all devs to change their local keys as well, while not invalidating the actual security and integrity of your production server.