Are you an API consumer? Or, in other words, do your mobile apps use external APIs to provide content and functionality that engages with and excites your customers? If so, how do you prevent bad actors from stealing, or otherwise misusing, your access permissions? API security is a major challenge today.
Access to an API is very often controlled and tracked using API Keys. These are digital codes that identify what is accessing an API and they are used for many different purposes including usage tracking, controlling data access, rate limiting, and even billing. Unfortunately, without proper protection, API Keys do not really guarantee the origin of a request, and in practice they are often poorly protected. This post outlines how CriticalBlue's Approov service can help protect your API keys, along with your other sensitive data, and by extension the access to the external APIs used by your apps. (If you only develop apps against your own API, then please read this post to learn how to use Approov to lock access down to your own apps.)
One problem with API Keys is that they are required by every important access to the external API (and this normally equates to every access). Therefore, it is very common for mobile Apps to embed the key directly, or for it to be communicated to the app just prior to the remote access. This setup is pictured in the diagram below.
The problem here is that the API key is resident at some point in the runtime of your app, and there are several attack vectors which allow the key to be read. The likely attack to be tried first is a simple decompilation of your app. This will immediately expose API keys that have been embedded in plain text. Salting, dissolving, and/or encrypting your key can certainly hamper its recovery, but even if you successfully hide it, it is still vulnerable to active network attacks. These types of attacks eavesdrop on the communication between a running app and the server to read sensitive data like API keys. The environment of an untampered device, together with basic app security such as certificate pinning, help prevent casual attacks, however, more determined techniques such as breaking SSL and pinning ultimately mean that the key can still be stolen and used indefinitely.
A solution to this level of attack is to altogether avoid distributing the API key. One approach is to setup an API proxy, as part of your apps’ server-side functionality, as shown in the diagram below.
This configuration successfully hides your API key by never publicly exposing it. However, it hasn’t completely solved the problem. In this case, the attacker will be able to use your API key by targeting his traffic at the endpoints exposed by your proxy. It may be possible to restrict the attacker's options by limiting the functionality exposed by your proxy but this type of approach requires time and effort and imposes overheads on the maintenance and development of your codebase. With Approov, we can significantly reduce attack vectors by ensuring accesses to your API are restricted to verified instances of your app, and this protection includes any proxied endpoints. The following diagram shows how Approov integrates with your API access flow.
Approov's local library seamlessly integrates into the genuine app, ensuring its authenticity at runtime and issuing a time-limited token for it. A simple modification to your web service and proxy then allows tokens to be verified and any unexpected requests rejected.
This setup ensures that even if a bad actor does manage to steal a token, the results would not be catastrophic. Stolen authentication tokens have few prospects for enabling meaningful attack vectors as they are constrained to a single app instance and limited in time, while the use of strong cryptography eliminates the risk of token generation by an unauthorised party.
In this setup, the proxy implementation becomes trivial:
1. Approov attestation is integrated with your app
2. All incoming traffic is verified as originating from your app, thereby protecting both your API endpoints as well as the external APIs that you use
3. An external-API-specific-proxied-endpoint uses a simple text replacement of the base URL to calculate the proper API endpoint for the request
4. The API key is added to the request
5. The request is forwarded.
The Approov service makes it easy and cost-effective to protect your API as well as disallow third parties to gain access to the external APIs you use, safeguarding from data leaks, provisioning failure and unexpected costs. Making the switch from API keys to a comprehensively protected API does not have to be strenuous. Tokens can simply be sent to your web service where API keys were previously used, at an immense gain in API security.
