Your Problem
They provide me with an API token which I use to make the API calls from my android mobile app (react native)
I know it is a bad practice to store this API token on the mobile client because attackers might still it and use my quota and money.
Yes, its indeed a very bad practice, but at least you are aware of the risks, while a lot use this approach without realising how easy its for an attacker to grab such secrets (Api tokens, API Keys, whatever you name them).
In a series of articles I wrote on Mobile API Security I show how easy it can be done with static analyses and with a MitM attack:
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.
Some attackers prefer to go straight to MitM attack, because they will learn how the App communicates with the API backend and will extract the secrets used, plus the blueprint they need to use for making the request and to parse the responses.
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.
Possible Solutions
Reverse Proxy
The trivial solution is to build a backend but I don’t want to start implementing all the original API methods, I just prefer to use it directly from the client.
You don’t need, you just need that your backend proxy the requests to the Third Party API you use on your mobile app, that in your case seems to be only for OpenAPI.
For example, when your mobile app needs to make a request to openapi.io/some/resource instead it makes it to your-reverse-proxy.com/some/resource that will then grab the /some/resource part and build the request to OpenAPI openapi.io/some/resource, adding the API token header to it, that now it’s securely stored in your Reverse Proxy server.
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.
A recurring theme in this article was the advice not to access Third Party APIs directly from a mobile app. As we have discussed, once your mobile app is released any secret in it becomes public, thus up for grabs by attackers to use on your behalf. If you are not careful you will be the one paying the bill or finding that your free tier resources have been exhausted by someone else.
The draw back of this approach is that you still have an API Key that you need to secure, the one to access the Reverse Proxy, but at least you are not exposing your OpenApi secret and you can use several mechanisms to throttle requests and to secure access to your Reverse Proxy to ensure that only answers to requests from genuine and unmodified instances of your mobile App.
Runtime Secrets Protection
You can devise or use an off the shelf mechanism to deliver the secrets to your mobile app just-in-time of them being required to be used on the API Request being made to OpenAPI, but you need to ensure that the secrets are only delivered to genuine and unmodified instances of your mobile app, that are not under a MitM attack, being tampered/instrumented at runtime with tools like Frida, otherwise your secret it will be easily extracted by hooking to the function that adds them to an header in the API request or by intercepting the request with MitM attack, even when the communication channel it’s secured with certificate pinning, because it’s not that hard to bypass in a device the attacker controls.
In my reply to the question Storing Api Keys Securely in Flutter or Sending Payment Details to my Server? I go in more detail on the Runtime Secret Protection approach.
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
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.