This blog describes how to get complete end-to-end protection for your API keys and other secrets, every step of the way from your chosen Secret Vault to the mobile app. We use the example of Approov working with Microsoft Azure Key Vault to show how to get secrets out of mobile app code in a way that never exposes them to hackers.
According to an article in Security Boulevard, “96% of organizations report secrets sprawled in code, configuration files, and CI/CD tools” in 2024. The same article tells us that over 100,000 public GitHub repositories leaked keys, and 70% of organizations experienced a secret leak in the last two years. Multiple recent reports also show that API Keys are still easily available in widely deployed mobile apps. Credential management is the number 1 risk on the OWASP Mobile Top Ten.
It is not a surprise that organisations are evaluating better ways to securely manage secrets such as certificates and API keys. There are companies specializing in the space, such as Conjur Cyberark and Akeyless Vault. The major cloud vendors also have offerings which are deeply integrated with their cloud services: AWS has AWS Secrets Manager and Microsoft has Azure Key Vault, which appears to be widely deployed by Azure customers. These solutions provide secure lifecycle storage and management of secrets like API Keys, certificates and encryption keys.
Secret Vaults like Azure Key Vault have reached broad adoption and are increasingly standard in cloud-native environments.
However, the prevalence of secret sprawl and breaches underscores that these tools must be paired with:
And last but not least, what happens when the secrets leave the Secret Vault matters too. Storing the secrets is just one link in a long chain, which is only as secure as its weakest link. The path secrets take from the vault to the app, how the app employs them and how they are communicated to APIs can all provide multiple opportunities for them to be harvested by hackers.
If secrets are in app code, they are easy to find and extract. You obtain the APK or IPA, reverse engineer it using JADX, APKtool or Ghidra and search for promising strings. It's worth noting that obfuscation won’t stop this. Decompiled code may have mangled names, but API keys often appear as plaintext strings. You can also use tools like Ghidra, IDA Pro, or Radare2 to analyze native libraries to see if anything interesting can be found.
You could also try dynamic analysis to extract secrets by using a tool like Frida to hook functions at runtime, and intercept API client initialization to dump API keys from memory.
Tools like Objection can automate some of this. Attackers extract JWTs, tokens, or API keys from memory or logs on rooted devices.
Hackers can use a proxy like Burp Suite or mitmproxy to inspect Network Calls at runtime to Intercept API requests to look for Authorization headers, API keys in URL params, or request bodies.
Apps without TLS pinning allow MITM interception of API keys/tokens but even if HTTPS pinning is implemented, tools like Frida can still be employed or you could bypass pinning with Objection.
So storing any "secrets" directly in code or config files leaves them vulnerable to breaches and exposes your app to serious risks. However the app needs API Keys to access backend services so how can we make sure they can be delivered safely and never be exposed?
What is needed is a way to only deliver secrets to an app when they are needed in a secure way and ONLY when the app is validated as genuine and the device environment is validated as safe. This combined with solid MitM defenses will keep secrets safe.
The way to truly protect your secrets is to combine industry leading app attestation and device integrity checks with the secret management, drastically reducing the chance of your secrets like API keys getting into the wrong hands - here is how it works:
Approov can secure and manage any secrets that an app needs, including API keys for owned or third party applications. Rather than hardcoding these into your app, where they are always vulnerable to reverse engineering extraction, an app protected by the Approov SDK simply obtains them at runtime from the Approov cloud service.
Before any secret is provided, Approov performs a deep inspection of your mobile app and the device it is running upon, and only if integrity checks are passed are the secrets passed to it at runtime. This ensures that sensitive API secrets are not being continuously stored or delivered to unsafe places. Unlike other mobile app hardening or obfuscation solutions, they are never even in the app until it is shown to be safe at the moment the secrets are required. If the checks pass, the key is retrieved and Approov SDK replaces API key placeholder with the retrieved key and sends the request.
Outgoing requests that may contain the secrets are pinned, ensuring they cannot be extracted by a Man-in-the-Middle (MitM) attack.
Crucially, secrets can be rotated easily as needed, without the need to update the app. This eliminates the risk of secret exposure damaging your business.
Lets take a look at Azure Secret Vault as an example of how this works in practice. As always there are different ways to do this effectively, depending on the particular use-case. Lets break it down:
Depending on the use-case, Options 2 and 3 are best. Either will keep your critical API secrets away from dangerous devices, compromised apps and… hackers. It also means you can manage and update them easily and quickly whenever you need to.
See this Approov Knowledge Base Article for more detail on the options and detailed implementation steps for Azure Key Vault Integration.
This approach works with any of the major Secrets Vaults and provides a path to better security for API keys and other secrets. Combining best-in-class app and device attestation with your choice of Secrets Vault is the only way to ensure end-to-end protection for your precious secrets.
Together we can get secrets out of your mobile code and into a safe place. Approov are experts on mobile app and API security and we would love to talk about your use-case.