As I am currently working a lot with mobile applications a question arised:

How to properly store and transmit API keys within mobile applications?

When I analyze mobile applications most of the times it is easy with the right tool to extract secret information (e.g. dump the keychain, reverse engineer crypto functions, detect hardcoded secrets with static analysis, ...) from the app. Therefore often is is possible to get a used API key at rest.

The other way is to monitor the traffic and perform a MITM attack. Therefore the API keys can often be sniffed at transit. Even if certificate pinning is used, there are easy ways to circumvent client side mechanisms like that.

Now I would like to get a understanding how to mitigate the risk, that someone like me can have access to these used API keys. What is the best practice to communicate via a mobile app with a remote API, that requires an API key?

1 Answer 1


My congratulations. You seem to be a very informed developer in terms of security and that is always good to see :)

The Difference Between WHO and WHAT is Accessing the API Server

Now I would like to get a understanding how to mitigate the risk, that someone like me can have access to these used API keys.

First I would like to clarify a usual misconception that arises often among developers of any seniority level, that is about knowing the difference between who vs what is in an API request.

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 API server, but I will extract here the main takes 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 your API server will be able to Authenticate and Authorize access to the data, and think about the what as the software making that request in behalf of the user.

Now, I hope we are in a better mindset to find some possible solutions to your questions.

Locking Down the API Backend to the Mobile App

How to properly store and transmit API keys within mobile applications? What is the best practice to communicate via a mobile app with a remote API, that requires an API key?

So, usually mobile apps use the API key to identify themselves to the API backend, but this not enough for the API backend to have a very high degree of confidence that the request is coming from what it expects, a genuine and unmodified instance of the mobile app.

Depending on your budget and resources you may employ an array of different approaches and techniques to defend your API server, and I will start to enumerate some of the most usual ones.

You can start with reCaptcha V3, followed by Web Application Firewall(WAF) and finally if you can afford it a User Behavior Analytics(UBA) solution.

Google reCAPTCHA V3:

reCAPTCHA is a free service that protects your website from spam and abuse. reCAPTCHA uses an advanced risk analysis engine and adaptive challenges to keep automated software from engaging in abusive activities on your site. It does this while letting your valid users pass through with ease.

...helps you detect abusive traffic on your website without any user friction. It returns a score based on the interactions with your website and provides you more flexibility to take appropriate actions.

WAF - Web Application Firewall:

A web application firewall (or WAF) filters, monitors, and blocks HTTP traffic to and from a web application. A WAF is differentiated from a regular firewall in that a WAF is able to filter the content of specific web applications while regular firewalls serve as a safety gate between servers. By inspecting HTTP traffic, it can prevent attacks stemming from web application security flaws, such as SQL injection, cross-site scripting (XSS), file inclusion, and security misconfigurations.

UBA - User Behavior Analytics:

User behavior analytics (UBA) as defined by Gartner is a cybersecurity process about detection of insider threats, targeted attacks, and financial fraud. UBA solutions look at patterns of human behavior, and then apply algorithms and statistical analysis to detect meaningful anomalies from those patterns—anomalies that indicate potential threats. Instead of tracking devices or security events, UBA tracks a system's users. Big data platforms like Apache Hadoop are increasing UBA functionality by allowing them to analyze petabytes worth of data to detect insider threats and advanced persistent threats.

All this solutions work based on a negative identification model, by other words they try their best to differentiate the bad from the good by identifying what is bad, not what is good, thus they are prone to false positives, despite of the advanced technology used by some of them, like machine learning and artificial intelligence.

So, you may find yourself more often than not in having to relax how you block the access to the API server in order to not affect the good users. This also means that this solutions require constant monitoring to validate that the false positives are not blocking your legit users and that at same time they are properly keeping at bay the attackers.

A Possible better solution

Regarding APIs serving mobile apps a positive identification model can be used by implementing a Mobile App Attestation solution that attests the integrity of your mobile app and device its running on before any request is made to the API server.

I recommend you to read this StackOverflow answer I gave to the question How to secure an API REST for mobile app?, especially the sections Hardening and Shielding the Mobile App, Securing the API Server and A Possible Better Solution.

In a nutshell, the Mobile App Attestation solution will allow the API backend to identify with a very high degree of confidence that what is making the API request is indeed a genuine and unmodified instance 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.


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.

  • Thank you for the detailed answer. There are a lot of things I can learn from your approach. The thing with mobile app attestation is, that with enough resources it is always possible to circumvent these mechanisms. "The reverse engineer always wins" :D I can confirm that OWASP is doing a great job there and I am actively working with the MASVS and MSTG.
    – rumpel
    Apr 1, 2021 at 7:12
  • The mobile app attestation solution when correctly implemented(no decisions in the mobile device) and kept up to date with latest threats is very hard to beat, and also protects the API backend.
    – Exadra37
    Apr 1, 2021 at 10:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .