Hide that API Key
Relying on obfuscation such as ProGuard or DexGuard does not void #1 or #2 above, so how does one solve this issue?
While ProGuard or DexGuard don't solve the issue they will make it harder, by renaming the name that the API keys is associated with, while if the API key is hidden in native C code the string of it will not be associated with any reference when performing static binary analysis, therefore making it more difficult to extract as I show in my article How to Extract an API key from a Mobile App with Static Binary Analysis:
The range of open source tools available for reverse engineering is huge, and we really can't scratch the surface of this topic in this article, but instead we will focus in using the Mobile Security Framework(MobSF) to demonstrate how to reverse engineer the APK of our mobile app. MobSF is a collection of open source tools that present their results in an attractive dashboard, but the same tools used under the hood within MobSF and elsewhere can be used individually to achieve the same results.
During this article we will use the Android Hide Secrets research repository that is a dummy mobile app with API keys hidden using several different techniques.
While this solution makes it very difficult to extract the API key with binary analysis, doesn't make it impossible, but easier approaches exist to extract the API key, like by doing a MitM attack as I demo in my article Steal that Api Key with a Man in the Middle Attack:
In order to help to demonstrate how to steal an API key, I have built and released in Github the Currency Converter Demo app for Android, which uses the same JNI/NDK technique we used in the earlier Android Hide Secrets app to hide the API key.
So, in this article you will learn how to setup and run a MitM attack to intercept https traffic in a mobile device under your control, so that you can steal the API key. Finally, you will see at a high level how MitM attacks can be mitigated.
An instrumentation Framework can also be used in conjunction with the MitM attack to bypass certificate pinning when the mobile app is using it. A popular one is Frida:
Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.
Reverse Proxy Server
If we pay attention to those best practices it gives Don't but no clear Do's for Mobile apps that need access to, for example, a stock trading API.
Another common approach to solve the issue of storing API keys in the mobile app code is to delegate the responsibility for accessing Third Party APIs to a Reverse Proxy like I wrote in the article
Using a Reverse Proxy to Protect Third Party APIs:
In this article you will start by learning what Third Party APIs are, and why you shouldn’t access them directly from within your mobile app. Next you will learn what a Reverse Proxy is, followed by when and why you should use it to protect the access to the Third Party APIs used in your mobile app.
Now, this only shifts the issue from protecting the API key for the third party service, like the stock trading API, to protect the API key or any other secret/identifier used to access the Reverse Proxy, but with the advantage that you now have control of how the third party API can be accessed, while keeping the API key to access it out of reach of the mobile app attacker.
Using user authentication to protect access to the Reverse Proxy will limit the scope of the attack, but will not eliminate it, because the Reverse Proxy server needs to be able to distinguish the who from what is doing the request, and in my experience I have seen that developers of any seniority are not often aware of this difference or have a misconception about it.
The Difference Between WHO and WHAT is Accessing the API Server
I wrote a series of articles around API and Mobile security, and in the article Why Does Your Mobile App Need An Api Key? you can read in detail the difference between who and what is accessing your backend, be it an API server or a Reverse Proxy server. I will extract here the main takes aways from it:
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
So think about the who as the user the Reverse Proxy server will be able to Authenticate and Authorize access to the third party service(stock trading API in your example), and think about the what as the software making that request in behalf of the user.
Hardening the Reverse Proxy Server
If we pay attention to those best practices it gives Don't but no clear Do's for Mobile apps that need access to, for example, a stock trading API.
The Reverse Proxy server can be equipped with User Behavior Analytics(UBA) solutions to give it the ability to distinguish from who vs what is doing the request, but this will be done in a best effort basis, based on historical data used by the Artificial Intelligence algorithm to score the probability of being a human or not doing the request, aka the who.
While UBA solutions will reduce significantly the attack surface, it's still a negative identification model, due to the occurrence of false negatives and positives, and will require constant monitoring of the policies/rules being used by the algorithm to strike the best balance between not blocking too many legit users and not letting too many attacks pass by.
A positive identification model can be used instead, by employing the Mobile App Attestation concept as I recommend in this answer I gave to the question How to secure an API REST for mobile app?, on the section A Possible Better Solution.
So, the Mobile App Attestion in a nutshell can be described as a solution that will be able to lock-down, with a very high degree of confidence, the Reverse Proxy server with the mobile app, because the Reverse Proxy server will now be able to only accept requests from what it expects, aka genuine and untampered versions of the mobile app.
Do You Want To Go The Extra Mile?
In any response to a security question I always like to reference the excellent work from the OWASP foundation.
For APIS
OWASP API Security Top 10
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
For Mobile Apps
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.