How to make sure API requests come from our mobile (ios/android) app?

Question

We're building a mobile app and want to implement some kind of authentication to make sure the API is only being accessed by our app. The users of the app are anonymous, with no logins, though I do identify them through the device id for maintaining settings and such.

The easiest approach seems to be generating a Guid / API Key that I send with every request over SSL.

What worries me is the possibility that a malicious person with a lot of free time would download the app, decompile it to get the API Key and the JSON requests, and then trash my database as best they can.

Is SSL, an API Key, a Device ID, and an API with as-constrained-as-possible calls good enough? Should I be taking a different approach? Are my fears founded or baseless?

Answer 1

Do NOT embed a single API key in the app. Your concerns are valid regarding the effect of malicious users. Also, you have a serious vulnerability in your current setup where you could have a malicious API user change other user's preferences by providing fake UDIDs.

Instead, create a "registration" service that is called upon first time app startup on the device which generates and returns a GUID based on the UDID. Store the GUID in your device local user preferences and on the server. Keep track of the GUID and match it up with the UDID on every request on your server.

Make sure all of this occurs over SSL.

With this approach there is no embedded master API key to be abused. Also, you can blacklist abusive users by flagging GUID/UDID combinations and you can also eliminate your existing issue of potential masquerading of existing registered devices. However, you cannot prevent malicious registering of devices that have not already registered with your service. That will always be a potential hazard of using a device id as a user identifier.

There are even better and more established authentication mechanisms that take a better approach, ie. OAuth, JSessionIDs, etc. that you should take a look at.

Also, in the future you should not be using the UDID to identify your users since access to it has been deprecated. You can mimick the UDID for your purposes by creating a custom device GUID on the device upon application installation and saving it in your local user preferences.

Answer 2

We're building a mobile app and want to implement some kind of authentication to make sure the API is only being accessed by our app. The users of the app are anonymous, with no logins, though I do identify them through the device id for maintaining settings and such.

The process of locking down an API server to only reply to request of a genuine instance of your mobile app is already pretty hard when user authentication is involved, but trying to do so with anonymous users is really a big endeavor, let's see why...

The Difference Between WHO and WHAT is Accessing the API Server

First, let's start by clarifying a misconception that usually find among developers of any seniority, that is about the difference between who and what is accessing an 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 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.

You can hink about the who as the user that the API server is 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.

In your use case identifying the who becomes more difficult once they are anonymous, but either way you still have to identify what is doing the request on its behalf, be the user anonymous or not, and this seems to be the missing piece that almost everyone seems to miss when trying to lock-down the API server with a genuine instance of their mobile app.

Reverse Engineering

What worries me is the possibility that a malicious person with a lot of free time would download the app, decompile it to get the API Key and the JSON requests, and then trash my database as best they can.

Reverse engineering an app nowadays(2021) doesn't require a lot of free time, neither a lot of skills, because a lot of Open Source tools exist to help with this task as I outline and demo 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.

Your Questions

Are my fears founded or baseless? No, they aren't baseless, by the contrary are well founded.

Is SSL, an API Key, a Device ID, and an API with as-constrained-as-possible calls good enough?

After you have reading the difference between who* vs what is accessing your API server I believe that you gained enough insight to understand that this will be not enough for the API server to identify with a very high degree of confidence what is doing the request.

For example, the DeviceID being used can be extracted with a MitM attack as I outline and demo for extracting an API key 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.

A Possible Different Approach

Should I be taking a different approach?

Security is all about adding as many layers of defense as possible and required by law to each use case.

So, yes you should and I encourage you to read other replies I gave in Stack Overflow to understand how the Api Server security can be hardened and ultimately how you can lock-down the API server with genuine instances of your mobile app by employing the Mobile app Attestation concept that will allow the API server to identify what is doing the request with very high degrees of confidence:

For example, I recommend you to read this 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.

So, on top of what you may be already doing to identify the anonymous user, you could add the Mobile App Attestation solution to ensure that a script is not able to pretend to be the anonymous user using a genuine and untampered version of your 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.