I have mobile app created by react native and I have backend server, which can start payment session or send e-mail when we request correct endpoint and passes correct api key. Now I'm storing backend api key in .env file, but it isn't a scurity way - https://reactnative.dev/docs/security#storing-sensitive-info
I don't want everyone who knows endpoint and will discover api key could use my backend API for example by Postman requests.
What can I do to protect my backend API in this case?
First, you need to bear in mind that one thing is to protect secrets from leaking from the environment where you run the backend code or build you mobile app binary release, and another thing is to protect the secret when it's backed into the mobile app binary or when the mobile app is running in a mobile device.
Now I'm storing backend api key in .env file, but it isn't a scurity way - https://reactnative.dev/docs/security#storing-sensitive-info
The use of an .env file is widely used practice to avoid hardcoded secrets in your code, thus this file must be always present in the .gitignore file. Alternatives exist, like using vaults:
Vault is a tool for securely accessing secrets. A secret is anything that you want to tightly control access to, such as API keys, passwords, certificates, and more. Vault provides a unified interface to any secret, while providing tight access control and recording a detailed audit log.
Now, this approach works very well for code that runs in a server, but for mobile app development the only advantage is that you don't have the secret hard-coded in the source code of the mobile app, thus you don't get it leaked in your Git repo(provided you have not forgot to have .env in .gitignore), but you will get the secret as normal string inside the mobile app binary, and this is so easy to reverse engineer with static binary analysis, as I describe 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.
As I say in the article, you can even use the strings command in Linux to extract it.
https://reactnative.dev/docs/security#storing-sensitive-info
Please, don't follow this advice they made, unless:
If you must have an API key or a secret to access some resource from your app, the most secure way to handle this would be to build an orchestration layer between your app and the resource. This could be a serverless function (e.g. using AWS Lambda or Google Cloud Functions) which can forward the request with the required API key or secret. Secrets in server side code cannot be accessed by the API consumers the same way secrets in your app code can.
Why? Well how do you protect the access to that orchestration layer? From their description it seems it isn't protected, thus all an attacker needs to do is to perform a MitM attack to your mobile app in a device he controls, and learn how the app communicates with this orchestration layer, and then we can do the same outside the mobile app. The worst part is that this orchestration layer is literally open to the world, thus letting anyone to do what you are afraid of:
I don't want everyone who knows endpoint and will discover api key could use my backend API for example by Postman requests.
Let's see the unless bit...
Now, if you protect the access to the orchestration layer with a secret, then you almost get back to square zero, but if your app is communicating with more then one backend, like using several Third Party APIs, then using a Reverse proxy(orchestration layer) is a good approach as I describe in my 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.
By now you may be wondering about how you will secure the secret to access the Reverse Proxy at runtime in your mobile app???
In the article I linked above for extracting the API key you may have noticed that I used the repo android-hide-secrets to demo some different approaches to hide them in the binary, being the most effective the one that uses Native C code. While this makes it hard to extract the secret with static binary analysis, it doesn't give you any protection against runtime attacks, like the ones that can be performed with instrumentation frameworks, like 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.
With instrumentation frameworks you can even steal a secret that was stored encrypted in the mobile device with all the best state of the art techniques provided by both iOS and Android operating systems, because the attacker will hook into the function that returns the secret unencrypted for use in the request.
This is pretty scary, because with instrumentation frameworks endless possibilities to attack a mobile app at runtime, one may think it's doomed to fail to protect the code at runtime, but its not game over yet, you can still resort to the Mobile App Attestation concept, and for that I recommend you to read this answer I gave to the question How to secure an API REST for mobile app?, especially the sections Securing the API Server and A Possible Better Solution.
The Mobile App Attestation concept may be the answer you are looking for to this question:
What can I do to protect my backend API in this case?
Always, remember that security is about adding as many layers of defense as you can afford or are legally required to do. This is nothing new, just remember how castles defenses were composed of several layers.
In any response to a security question I always like to reference the excellent work from the OWASP foundation.
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.
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.
