Your Problem
I searching for a solution to make private the communication between my mobile application and my server.
From the moment you use HTTPS the communication between your mobile app and server is private, unless a MitM attack is being carried out successfully by an attacker, which usually is done in an environment the attacker can control with the help of open-source tools to make the task easy.
Maybe you were trying to say that you want to make your API private to your mobile app?
If yes, unfortunately APIs are only private when they only serve requests from inside a private network. From the moment that an API is accessed via the internet it's a public API, despite not being documented anywhere on the web and/or having tight security. This is because an attacker can reverse engineer the application using it and perform runtime attack to enumerate all API endpoints and understand how they work.
The Difference Between WHO and WHAT is Accessing the API Server
Given that my application doesn't need user login, what can I do?
Before we dive on how to secure a mobile app that doesn't require user authentication we need to demystify a usual misconception around who vs what is accessing the 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.
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. So, in your case you are proposing to authenticate on the server what is making the API requests with a mechanism usually used to identify who is in the request. I hope that by now you are realising that this approach falls short and will not suffix to secure your API backend.
After you understand the difference between who vs what, and it's ingrained in your mindset, you will look into mobile API security with another perspective, and you will be able to see attack surfaces that you never though they could exist.
MitM Attacks
In the first scenario, it's simple. In the mobile application, at every http call, I will send the static token on header. My doubt is on security, because someone can intercepts http calls and copy the static token.
Yes, an attacker can easily extract your static token by intercepting the API request with a MitM attack, and open source tools exist to make this possible to achieve by non developers. Read my article
How to MitM Attack the API of an Android App to understand how a tech savy person can do it:
Performing a MitM attack against an HTTPS channel requires the capability for the attacker to be able to add the proxy server Certificate Authority (CA) into the Trust Store of the device running the mobile app and a popular approach is to manually upload the CA to the device, but this comes with some challenges, that may require to root the device and/or repackage the mobile app.
An easier way exists, and in this article I will show how to use an Android Emulator with a writable file system that will allow us to install the proxy certificate directly into the system trusted store, without the need to root the emulator or make changes in the mobile app.
To mitigate against MitM attacks you must implement certificate pinning, which increases the skill set required to perform a MitM attack. The attacker will need to resort to reverse engineer the mobile app to remove the pinning check and repackage it to perform the MitM attack, or use an instrumentation framework to modify the result of the pinning check at runtime, thus making it to always succeed during the MitM attack. You can read the article on How to Bypass Certificate Pinning with Frida on an Android App to learn how an attacker does it:
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.
So, pinning increases the difficulty for an attacker to succeed in a MitM attack, but doesn't eliminate the threat completely. You also need to be aware that pinning requires the pin to be hardcoded in the mobile app code, which makes certificate rotation in the API backend a complex task that needs to be coordinated between developers and the operations team, because it requires a release of a new mobile app version ahead of the certificate rotation. An alternative solution is to use dynamic certificate pinning but that isn't available as an open source solution (as far as I am aware), neither is an easy thing to implement securely on your own, but its worth to consider it.
Reverse Engineering
In the second scenario, I will authenticate with email and password and manage the session with the jwt token. The doubt is on the fact that the credentials are embedded inside the application code. I don't know if someone can access this data in this way.
Any sensitive information inside the mobile app binary can be retrieved with static binary analysis. A lot of open-source tools exist to make this task easy. For example, you can use the Mobile Security Framework (MobSF) to decompile and analyse a mobile app binary, which will reveal all potential secrets stored in the binary. Learn more 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 the MobSF results aren't satisfactory or you want ot dive deeper then ou can also use the Linux grep and strings commands on the decompiled binary to make your own searches or narrow doen the results given by MobSF.
Possible Solutions
Given that my application doesn't need user login, what can I do?
What do you suggest me? Have you any other suggestions?
The most effective solution to your use case may be to add remote mobile app attestation capabilities to your mobile app and leverage them to remove hard-coded secrets from your mobile app. Keep reading for more details and links to other Stackoverflow answers I gave that will go in more detail.
Remote Mobile App Attestation
If you want to use credentials in any form to authenticate the mobile app to the API backend then you need a mechanism to allow the backend to know in real-time that the mobile app isn't under attack, not running in a rooted or jail-broken device, in other words that is a genuine and unmodified instance of your mobile app. You need to add remote mobile app attestation capabilities to your mobile app as I suggest in this answer I gave to the question How to secure an API REST for mobile app?, where I recommend you to pay special attention to the sections Hardening and Shielding the Mobile App, Securing the API Server and A Possible Better Solution.
Runtime Secrets
If you include remote mobile app attestation capabilities into your mobile app then you can leverage them to have your secrets delivered just-in-time of being necessary to make an API request. The runtime secrets will be delivered only to mobile apps that aren't under attack and pass the app and device integrity checks performed by the remote mobile app attestation. I 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 is proposed as a possible solution.
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.
