I will cut to the chase in this blog. Protecting and managing the API keys MUST be number one on your security to-do-list. A wave of recent breaches show just how exposed mobile apps are to API key abuse. This blog explains how to make a plan to fix the issue right now.
OWASP recently emphasized that secrets security is the most critical issue for mobile applications in their updated 2024 Mobile Top Ten Risks. The exposure of sensitive data, such as API keys and credentials, remains a significant threat. When these secrets are exposed, attackers gain easy access to services, APIs, and potentially backend systems without needing further exploits. As a result, poor secrets management can lead to severe security breaches, making this issue a top priority for app developers and security teams.
Our own research and many other reports show the extent of the problem. A report from Symantec in October 2024 found that popular apps with millions of downloads exposed AWS and Azure credentials. The Internet Archive had a nightmare scenario where even after a breach was reported attackers continued to use stolen Zendesk API keys, suggesting that the organization had some challenges rotating compromised keys when an issue was identified. There are many other examples showing the extent of the problem so it's not a surprise that credential management is number 1 on the OWASP Mobile Top Ten.
The most notable points OWASP highlights include:
- Client-Side Secrecy is Nearly Impossible: No matter how well secrets are obfuscated or encrypted, attackers with enough skill and resources can extract them from mobile apps. This means that the best approach is to remove secrets from the client-side altogether and handle them in the backend, where they can be better protected. (Great advice, but the secrets need to reach the app and the backend needs to verify it’s communicating with the correct app, more on this below).
- Hardcoding Secrets is a Major Vulnerability: One of the most common issues developers face is embedding API keys, passwords, or tokens directly into the app's code. This makes the app an easy target for reverse engineering, especially when static analysis tools are widely available to extract these hard coded secrets.
- Mitigating Secrets Exposure: Best practices to minimize this risk include moving secrets to the backend, using secure storage APIs like iOS Keychain or Android Keystore for user credentials, and implementing certificate pinning to secure communications between apps and servers. Additionally, regular rotation of keys and secrets is essential, as well as real-time monitoring to catch leaks early. (See dynamic pinning)
Organizations are advised to use tools that can detect hardcoded secrets during development and testing phases (See GitGaurdian’s blog on this). Approov, for example, emphasizes that rather than relying on device-side protection, it follows a run time Zero Trust model that assumes the mobile app and device are untrusted until proven otherwise, making it a robust solution against these common threats.
OWASP provides some good suggestions to mitigate this risk, but the PRACTICAL “how” app developers can solve this is left to interpretation. The only practical way to ensure secrets are perpetually safe is to adopt a dynamic, zero trust security approach for your mobile app. The suggestion to keep secrets in the backend where it’s safe is a good one, but then how does the app get the secrets and how does the backend know it’s talking to the legitimate app in a secure client environment? Attestation is the only way to accomplish this in a scalable, practical, and highly secure way.
Because of the unique way Approov can get attestation information about the device and the application, API keys can be delivered just in time to the application but only when the device and app are verified as genuine and unmodified. In this way, secrets are always secure and never appear in your code. And when you need to you can rotate them immediately.
Want to see how to do this in action? Connect with me on linkedin or book a demo from our website.
