Careless API Keys30 Jan 2018 #Best Practices #Security
The other day, my friend got a really simple interview question:
“Why should a developer never check API keys into git?”
Every developer should know this.
You shouldn’t check in API keys (or any credentials) because others can easily take the key and impersonate you, gain unauthorized access to your data or services, DDoS, or potentially drive up your bills (for paid services).
While most developers are familiar with the best practices involving protecting their keys, there are a surprising number of people that don’t follow them. A simple search on GitHub with two random characters (
API_KEY=q9) returns over a thousand results.
It is scary what you can find: everything from Stripe keys to AWS credentials. Config files with keys, immediately followed by a comment containing:
// PROD key // API_KEY: <production key right here in plaintext>
These unsecured credentials are often targeted by bots, who scour GitHub for live API keys. There are many horror-stories, including this one, of people who accidentally committed their AWS keys, only to realize a few days later that they had accrued a huge bill from unauthorized cryptocurrency mining on their EC2 instances. In that instance, Amazon support was willing to remove the charges from his AWS account. However, many other companies might not be so lenient or forgiving.
The moral of the story is: be mindful of what you commit. Figure out how to properly store your keys and credentials. Learn to use your
.gitignore, and double-check what you commit. It might take a few extra seconds, but it could save you from a huge headache in the future.
PS: If you realize that you’ve already accidentally commited API keys into your git history, here is a great guide by GitHub on how to properly scrub the key.