Reverse Engineering
I have a couple of API endpoints that I want to allow only certain apps like the Xamarin mobile app or apps with a secret API key to be able to call the endpoint.
Obviously, with this method I have to publish this secret API key with the mobile app which I see as a security concern, given that somebody can reverse engineer the .apk and extract the API key.
You are correct. Having the API key in the mobile app code doesn't protect it from being extracted with static binary analysis and a lot of open source tools exist to make it an easy task. In addition, if an attacker cannot extract it with static analysis then they can resort to runtime attacks, where they can perform a MitM attack and/or use instrumentation frameworks to hook into the code during at runtime.
Static Analysis
My preferred tool is MobSF (Mobile Security Framework) and I show how easy an API key can be extracted with this tool in the 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.
If one uses apktool to decode the mobile app binary, then they can just use the Linux grep and/or the string command to find secrets in the mobile app.
Runtime Attacks and Instrumentation Frameworks
When an attacker doesn't succeed or doesn't want to spend time in static binary analysis then a MitM attack is the logical choice, that may require or not to use an instrumentation framework. For example, if certificate pinning is being used then an attacker needs to use an instrumentation framework to bypass it to be able to carry out the MitM attack, as I show in the article
How to Bypass Certificate Pinning with Frida on an Android App:
Today I will show how to use the Frida instrumentation framework to hook into the mobile app at runtime and instrument the code in order to perform a successful MitM attack even when the mobile app has implemented certificate pinning.
Bypassing certificate pinning is not too hard, just a little laborious, and allows an attacker to understand in detail how a mobile app communicates with its API, and then use that same knowledge to automate attacks or build other services around it.
Possible Solutions
Code Obfuscation
Bear in mind that some may recommend the use of code obfuscation, but code obfuscation only obfuscates the variable names where the API key will be hard-coded and/or the method name returning it, leaving the API key in plain text on the mobile app binary being installed in the mobile devices. When code obfuscation is used to hide secrets it will introduce a Maginot Line in the security defences, a false sense of security. Curious about the analogy, then read my blog post Is Code Obfuscation Worth it?
As a developer once said… It depends!!!
In a nutshell, it depends on what is motivating you to use obfuscation in the first place. If you plan to use only code obfuscation as a security measure then you may end up with a Maginot Line on your security defences.
In this article, we will first provide a brief lesson on World War II to understand how the French's impenetrable fortifications built to prevent invasion by Germany were easily circumvented. We will use this as an analogy to understand how attackers can do the same when they encounter code obfuscation being used as a technique to hide hardcoded secrets in a mobile app.
Sure, one can add code/hardening/encryption to make it harder for attackers to perform code static analysis on the binary, but that will not stop the more skilled attackers or the ones with time to invest on breaking it, but as In the Maginot Line, a smart attacker just goes around it and performs a MitM attack.
Runtime Secrets
A best approach is to not have secrets on the mobile app binary and retrieve them at runtime.
A technique that I have seen being used involves retrieving secrets when the mobile app is first booted, after installation, or every-time is launched, but this means TOFU (Trust on First Usage), which an attacker can exploit to also grab those secrets.
To avoid TOFU I will recommend you to read my accepted answer to the question How to use an API from my mobile app without someone stealing the token where the Runtime Secrets Protection seems your best option.
In a nutshell you will have the secret stored in the cloud and have it delivered just-in-time of being used to your mobile app, but only if the same is not being under attack, running on a root or jaill broken device, isn't attached to a debugger or running in an emulator, which uses remote mobile app attestation to decide about the device and app integrity, not in-app decisions.
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.
For Web Apps
The Web Security Testing Guide:
The OWASP Web Security Testing Guide includes a "best practice" penetration testing framework which users can implement in their own organizations and a "low level" penetration testing guide that describes techniques for testing most common web application and web service security issues.
