Why should I hide API keys?

Question

I need to integrate my android app with dropbox, basically all I want is for the user to choose a file from his dropbox and give it to my app. In order to do that I'm using dropboxChooserSDK, and it requires an API key to access dropbox.

From my first instinct was to search on how to hide the key. Looking deeply into it I have noticed that there is no silver bullet to solve the problem (I should have expected as much).

On the other hand there doesn't seem like there is much harm in having my dropbox api key exposed to the world given the prupose of the key as explained in their reference documentation:

If you're building a developer tool on top of Dropbox, your developers will need their own Dropbox app keys

While we encourage developers to use our official SDKs and libraries, we know there are a lot of different approaches to building frameworks and APIs. Regardless of how an app makes use of the Dropbox Platform, we need to know what that app is so we can let users know which apps are accessing their data. For that reason, if you provide software or services that wrap the Dropbox Platform for other developers to use, those developers must still sign up for their own Dropbox app key.

But that made me think, about the question, how much effort should I put into hiding my API keys? My intuition tells me to use a back of envelope calculation to estimate the cost/benefit trade-offs individually, but I also read here that there is ongoing discussion about such problems (though I couldn't find it).

What's the general understanding regarding securing API keys?

Answer 1

I don't know anything about Dropbox in particular, but my understanding of API keys from other storage providers like Google Drive, Amazon S3, etc is that they allow users to log in either through their apps, or through 3rd party apps and they want to be able to track which is which. The quote in the question makes it sound like this is about privacy: letting end-users know which apps are accessing their data and be able to revoke permission on an app-by-app basis.

There is also often a billing angle: Google Drive, for example, offers a free service directly to end-users through their own apps, but charges some $/gb to developers who want to piggyback on their infrastructure inside another product. Whether that app developer charges that to their users through a subscription, or just swallows it as a cost of business, is up to them.

This is where API keys come in: without an API key, an incoming request to the Dropbox server is just a request; you know which end-user it is because they have logged in, but you have no way of telling whether they are using your app or some 3rd party app, and if so, who to bill the bandwidth to. By embedding an API key in your app, you are linking each request your app makes back to your developer's billing account.

Since Android .apk files are fairly easy to reverse engineer, an attacker could conceivably extract your API key, use it in their app, and you'd get the bill.

Is the effort of protecting the key worth the risk? That's up to you. If you monitor your usage frequently or have set some kind of usage cap / alarm and are confident you can revoke the key quickly if fishy things start happening, then you're probably fine.

---

UPDATE: As @XiongChiamiov points out in comments, you should also consider the disruption to service if you do need to revoke your key. Let's say you start seeing abnormally high billing or hit your pre-set usage cap. Your response would probably be something like:

• scramble to implement better API key protection in your app
• publish a security update to the Play Store with a new API key
• revoke the old one.

The Dropbox feature of your app will fail until users update their app through Google Play. This will certainly cause some confusion among your users. Whether this is a big enough risk to worry about at this point is up to you.