How to Eliminate Hardcoded API Keys from Your App

The Problem with API Keys

API keys are commonly used to authenticate your app to a backend API and, as such, operate like a password. API keys block any anonymous traffic and can be used to limit the rate of requests from any one particular app. API keys must be kept secret. If not, your app can be impersonated and API calls can be made by other parties, just as if your mobile app was making them.

Keeping API Keys Out of Source Code Isn’t Sufficient

In the case of mobile apps the compiled code is in the public domain and must be released through the app store. Even if they are obfuscated or hidden in some way, keys will still be compiled into or linked into your release package in some way and will appear in the app store.

Third-Party API Access from Mobile Apps

Consider the case where you have compiled your app and published it to the app store. As the app runs it will use the API keys embedded within it to access the services it is dependent upon:

Whenever an app accesses that individual API, that API key is copied from the code as it runs and then transmitted over the network.

The Risks of Stolen API Keys

So API keys can be reverse engineered from the code, or captured in transit from the mobile app to the backend. Any attacker has complete control of the device and the network it uses, so such attacks are relatively straightforward.

The risk obviously depends on the capabilities of the particular API whose key has been compromised. Data exfiltration from the API is the most obvious risk, but there are also many ways your service could be degraded or even completely blocked by hackers using stolen keys - e.g. to interfere with performance analytics, perform DDoS attacks on APIs, or incur 3rd party costs and misuse your APIs until service is blocked.

Approov Architecture

The below diagram illustrates the four-step flow of how Approov Runtime Secrets Protection works. This protection can be easily dropped into an existing app, that currently embeds API keys, with the minimum of changes:

The steps are as follows:

1. Approov account administration is simple. The Approov SDK is integrated with the app and any keys used are stored in the Approov cloud service. The app signature is stored by Approov.
2. At runtime, when the app makes a request that will need an API key, the SDK automatically gathers app and device environment integrity measurements and sends them to the Approov cloud.
3. The Approov cloud evaluates the measurements and, only if they are consistent with an official app running in an appropriate environment, are the API keys transmitted to the app. You have complete control of the security policies which cause a rejection.
4. The API keys are added to the requests as required so that the mobile app can authenticate itself to the backend. The API keys are only ever held temporarily in memory and communication with the backend is protected to ensure that the keys cannot be intercepted via a Man-in-the-Middle (MitM) attack.

Comprehensive Environment Checks

• Debug detection
• Root and jailbreak detection, including Android Magisk detection
• App tampering
• Emulator and simulator detection
• Running inside a cloner app
• Detection of Android automated app launch
• Detection of function hooking
• Advanced detection of runtime app instrumentation frameworks such as Frida
• Protections against late attachment of Frida and debuggers

In most cases several different detection methods are employed to provide high resiliency against attack. The core measurement gathering and detection logic is heavily defended, and it can also be updated over-the-air without the need for a new app release.

Approov is also under continual development to protect against the latest attacks seen across the full range of our customers. 

The interaction with the Approov cloud has a side benefit. Approov sees all the connections from different devices and Approov account holders get live and cumulative metrics showing what's actually happening in their apps.

Protecting API Keys in Transit

The app and device integrity measurements ensure that the API keys are only ever transmitted to valid instances of the apps. It is also necessary to ensure that there is no possibility that the API keys could be stolen in transit to the backend API by a Man-in-the-Middle (MitM) attacker. This is challenging, since pinning cannot be employed because the certificates used on a backend API server could be changed at any time in a manner not controlled by the app developer.

To solve this, Approov provides a facility called Managed Trust Roots: The managed trust roots within running apps can be dynamically updated by Approov as required. Thus if particular root certificates need to be removed or newly issued root certificates added then this can all be achieved without any need to update the app itself. Crucially though, these updates are only accepted if signed by Approov so an attacker cannot use this mechanism to subvert the trust store.

Quickstart Integrations

In order to make the integration of Approov straightforward there are a range of app quickstart integrations for many native and hybrid frameworks.  

Summary

Approov Runtime Secrets Protection frees you from needing to hardcode API keys in your mobile app. Concerns of reverse engineering and abuse are removed. Strong app attestation protection ensures that only an authentic app running on an uncompromised device can access them, and thus the APIs that they protect.

The TLS communication channel is protected with managed trust roots, providing an additional trust store within the app, that blocks any Man-in-the-Middle (MitM) attacks.

The API keys can be managed in the Approov cloud where they may be updated at any point, with only a 5 minute propagation time to all running app instances.

This is all achieved without any need to change the backend APIs and with a straightforward drop-in app integration approach.