We're Hiring!
We're Hiring!

How to Eliminate Hardcoded API Keys from Your App


Mobile apps typically communicate with several backend services over the Internet. Some services may be controlled by the owner of the app but some may be operated by 3rd parties.  

In either case, it is typical for access to these services to be authenticated by the use of an API key. Often the required keys are stored in the released app itself. This whitepaper explains why this practice is extremely dangerous and highlights the risks of such hardcoded API keys. It also shows how Approov’s Runtime Secrets Protection feature enables such keys to be easily eliminated from apps to avoid all the associated risks.


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:

Approov diagram - Running App with Embedded API Keys

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.

Approov Diagram Showing Risks of Stolen API Keys

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:

Approov Architecture (no background)

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.
With Approov protection in place,  only valid app instances running in uncompromised environments can access the API keys stored in the Approov cloud. Absolutely no changes to the backend APIs themselves are necessary.

As an additional benefit, API keys can then be easily rotated simply by administering the Approov account without the need to issue a new version of the app. All running app instances repeat their integrity checks at least every 5 minutes, so new API keys can be propagated to all app users within this period.
.

Comprehensive Environment Checks

Approov performs a wide range of app and environment checks as part of the measurement and subsequent attestation process:
  • 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.

 

Screenshot of Approov live threat analytics

 

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

Approov Quickstarts - icon montage

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.

 

Download the full version of the white paper

 How to Eliminate Hardcoded API Keys from Your App v4

 

Download the full version of the white paper

 

How to Eliminate Hardcoded API Keys from Your App v4

 


 

Contact us for a live demo

Our security experts will show you how to protect your revenue and business data by deploying Approov Mobile Security.

 

 


 

Subscribe to
Approov Newsletter

To be informed of the up-to-date industry news, the latest technology trends, and beyond.