15

I'm making use of google API for location (in Android, iOS apps).. Can the key be hardcoded? Or should it be protected? If It's sensitive, why is it sensitive and how can attackers exploit this?

2 Answers 2

12

The Google Maps SDK for iOS sends the app's API key to Google in such a way that any end user of the app can find the app's API key by using an HTTPS proxy. If you happen to be developing on a Mac, you can try this yourself pretty easily using the Charles proxy.

  1. Configure Charles to act as a proxy for clients4.google.com. On a Mac you'll need to make sure you're using the "alternative version" with full SSL proxying support downloadable from this page.

  2. Download and install the Charles SSL certificate for iOS devices by visiting this link on your iOS device.

  3. Configure your iOS device to use an HTTP proxy (this is available in the advanced options for your WiFi network, accessible via the little "i" button next to your WiFi network's name). Set the proxy server to the IP address of the Mac running the Charles application, and the port to 8888.

  4. Run your (or any) iOS app that uses the Google Maps SDK for iOS.

In Charles, you'll see POST requests go out to clients4.google.com, where the API key is visible as part of the request body.

So, to answer your questions:

  1. In terms of security it hardly matters if you hard code the key. Any end user can get your app's maps API key without ever digging into the app itself. In terms of convenience you might be better off fetching the maps API key from your own server so that if/when you need to update your maps API key you don't need to release a new version of the client app.

  2. The maps API key is not sensitive, in the sense that Google does not treat it as sensitive information. And in fact, even if Google obfuscated the keys by sending (say) a hash to their API instead of the key itself, a determined end user with a jailbroken device and a debugger could still get your API key by inspecting the parameter you pass to +[GMSServices provideAPIKey:]. So it's questionable that there would be any point in trying to treat the API key as sensitive information.

  3. An attacker can exploit the exposure of your API key by making requests to the Google Maps API that appear to be coming from your app. A group of malicious users could spam the API to use up your app's "courtesy" bandwidth, or to run up your bandwidth bill if you have billing enabled for the Google Maps API. If you (or Google) are keeping a close eye on your bandwidth usage, you could partially defend against such an attack by revoking and replacing the maps API key when your app's (apparent) usage of the maps API spikes.

4

Can the key be hardcoded?

If you mean hardcoding the key into the URL, well, creating a new key would mean changing it at the code level. Changing this at the code level could be avoided.

Should it be protected?

In most cases, the key, being a part of the request query, is out in the open. (If you do use POST instead, there are still ways of getting this information). But, as long as the request using your key does not come from your domain (HTTP referrers), Google will throw back an error.

How can attackers exploit this?

As a simple use case, assuming the per-user limits are not set right, one could launch a denial of service attack using the accessible API key.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .