THE API SERVER LOCK TO THE MOBILE APP
I have a mobile game that interacts with an API. I want this API to only be called from this mobile app. It's simple to explain but on the other hand, its simplicity makes me chaotic.
In Software Development it's common that things that are easy to explain may be very hard to implement, and this is one of that cases.
So what you want to achieve is to lock your API server to your mobile app, or by other words to ensure that you APi server only responds to requests comming from your genuine and un-tampered mobile app you have uploaded to the official stores.
You mention that are no users:
There are no users, therefore no user credentials. It's a open game that requests an image from the API.
But I think you may want to say that you don't have Authenticated Users, and even you had them you would only identify Who is in the request, not What is doing the request.
This is a common misconception among developers, no matter if junior or senior, thus it's important to properly clear it out in order you can develop an effective secure solution for your mobile app.
The Difference Between WHO and WHAT is Accessing the API Server
I wrote a series of articles around API and Mobile security, and one of them contains a good description on this difference, the article Why Does Your Mobile App Need An Api Key? is the one you want to read to better understand the difference between Who and What is accessing your API server, but I will extract here the main take aways 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.
Think about the Who as the user an 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.
So in your situation you are not worried about the Who in the request, instead you want to know What is doing the request so that you can lock your API server to your genuine mobile app.
Hardcoded Identifiers
Hardcoded secret/apikey/token etc. -> Nothing must be hardcoded
That's a very wise decison, because from the moment you release a mobile app, anything sensitive date inside it must be considered as compromised because a lot of open source tools exist to help anyone to perform static and dynamic analysis on a mobile app binary to extract that data and/or change behavior of the app. Examples of this type of tools are:
MobSF - Mobile Security Framework
Mobile Security Framework is an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing framework capable of performing static analysis, dynamic analysis, malware analysis and web API testing.
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.
Runtime Identifiers
Device ID or Advertising ID -> Good solution but any other apps also get this ID then call my API. Plus, any attacker can send anything as Device ID, right? So how can I verify this device ID is a real identifier for an existing device?
This identifiers are easily manipulated/extracted during run-time with framework like Frida or Cydia, thus they are open to exploited by an attacker as you already guessed.
Now if you are referring to more advanced identifiers like the Android SafetyNet and/or the iOS DeviceCheck, then I want to call your attention to some details:
Android SafetyNET
You may want to read my reply to the question Android equivalent of ios devicecheck that goes in great detail about what it is and what is not.
But in short it was not designed to be used as a stand-alone defence, as per Google own statement:
The goal of this API is to provide you with confidence about the integrity of a device running your app. You can then obtain additional signals using the standard Android APIs. You should use the SafetyNet Attestation API as an additional in-depth defense signal as part of an anti-abuse system, not as the sole anti-abuse signal for your app.
iOS DeviceCheck
Apple’s DeviceCheck solution is primarily designed to validate the identity and track record of a physical mobile device without the need to track any personal information about the device or its user:
Using the DeviceCheck APIs, in combination with server-to-server APIs, you can set and query two bits of data per device, while maintaining user privacy. You might use this data to identify devices that have already taken advantage of a promotional offer that you provide,...
And as they also say you can also use it for marking a device as cfraudlent:
...or to flag a device that you've determined to be fraudulent. The DeviceCheck APIs also let you verify that the token you receive comes from an authentic Apple device on which your app has been downloaded.
But bear in the words they use: to flag a device that you've determined to be fraudulent. So it's up to you to determine the device status, but remember that knowing a device is rooted or jail broken it's not the same as knowing What is making the request to the API server.
So should I use them?
Yes, because defense is all about adding as much layers as you can afford, but this will not solve your main issue, that is to know What is making the request to your API server.
Authentication Server
I am considering using AWS Cognito as an auth server.
No matter if Cognito or any other Authentication server they excel in identify, authenticate and authorize Who is in the request but they don't know how to do the same for What is doing the request.
A POSSIBLE SOLUTION
I want this API to only be called from this mobile app.
So how can I verify this device ID is a real identifier for an existing device?
In order to know that What is doing the request is indeed your genuine and unmodified instance of your mobile app you need to use the Mobile App Attestation concept, that I describe in this reply to the question How to secure an API REST for mobile app?, specially the sections for Securing the API Server and A Possible Better Solution.
DO YOU WANT TO GO THE EXTRA MILE?
I cannot finish my reply without referencing the excellent work from the OWASP foundation.
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 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.
