Building Resilient Mobile APIs in a Hostile Environment

Protecting your mobile application against client-side threats is a vital aspect of application security. However, one critical area that is often overlooked is the communication between your mobile app and its backend.

You may feel confident that a request came from your app (after all, you built it and the request uses secrets from your application), but that's a dangerous assumption. Malicious actors have effective tools and techniques that can allow them to:

• Intercept and modify traffic: By creating a proxy to intercept and modify requests made by your application, attackers can bypass standard TLS-based security.
• Extract static secrets: If your app embeds secrets used for backend communication, attackers can decompile the binary to retrieve and then reuse them in other apps or scripts. If your app is not protected or obfuscated, this generally takes only a couple of minutes. Depending on the strength of the code protection, you can make this more difficult – so that it would take an experienced attacker significant effort to retrieve any secrets. However, for risk modeling, you should assume that any static secrets built into the app will eventually leak, even with strong code protections.
• Modify your app: Attackers can easily alter your application behavior via hooking or static tampering. Once modified, a tampered app can be installed on any device, including non-rooted ones. These altered versions can manipulate outbound traffic and modify runtime behavior.
• Use your app on rooted/jailbroken devices: Modern Android protects against MITM attacks by ignoring user-installed certificates by default. While this secures the average user, a rooted device allows an attacker to elevate a malicious certificate to the system level, compromising the entire device's trust architecture.

Communication layer attacks

The first step in selecting an effective defensive strategy for your mobile app is understanding the different approaches that a malicious actor might use to target your communication layer.

Man-in-the-Middle (MITM)

In a MITM attack, the attacker positions themselves between the mobile app and the backend server to intercept and potentially modify communications between them. This is possible even when using TLS because the attacker can intercept the TLS handshake and present their own certificate to the app, tricking it into establishing a secure connection with the attacker instead of the legitimate server.

Generally, these attacks consist of the following steps:

• Interception: The attacker sets up a proxy server that intercepts all network traffic from the mobile app.
• Certificate spoofing: The proxy presents a fake TLS certificate to the mobile app, making it appear as if it is communicating with the legitimate server. The app validates this certificate and establishes a connection with the proxy.
• Decryption and modification: The proxy can now decrypt all traffic from the app, read it, modify it, and forward it to the legitimate server. Similarly, it can also intercept responses from the server, modify them, and send them back to the app.

Man-at-the-End (MATE)

In a MATE attack, the attacker compromises the mobile application itself rather than intercepting the communication channel. This is typically achieved through reverse engineering and dynamic analysis techniques, such as hooking or tampering.

This can be used to achieve the same goals as MITM but without needing to intercept the communication channel. For example, an attacker can use MATE to log secret information sent by the backend to the app or to modify requests sent by the app to the backend.

Bot farms

In a bot farm attack, the attacker automates the mobile application to perform actions without requiring user interaction. There are two different types of bot farms:

• Device bot farms: These use real devices or emulators to run a version of your client-side application that has been maliciously instrumented to interact with your backend (often using accessibility features to emulate user interaction).
• Headless bot farms: Once attackers have fully reverse-engineered your communication layer, they can then use scripts to make direct requests to your backend.

Defensive options

With a firm grasp of what a bad actor might do to exploit communications between your client-side app and the backend, we can look at the different defensive tools that are available to counter those attack techniques.

TLS

Obviously, you should always use TLS for all communication between your mobile application and your backend because it protects you from passive eavesdropping. However, TLS is not enough to protect against active attacks.

• Against MITM: By itself, TLS has a very limited impact. The attacker just needs to make sure the application trusts their certificate (e.g., by storing it in the device's trust store), and the app will establish a "secure" connection with the attacker proxy.
• Against MATE: Since the communication channel is not directly targeted in these attacks, TLS does not offer any protection.
• Against bot farms: Whether it is a device-based or headless bot farm, the attacker acts as a regular client, so TLS alone will not help.

Certificate pinning

Certificate pinning ensures that the app only accepts certificates signed by known Certificate Authorities (CAs) or only recognizes specific public keys. Since the MITM proxy's certificate is not on this trusted list, the application will reject the connection.

1. Pinning: The app stores the expected certificate or public key in its code.
2. Validation: During the TLS handshake, the app compares the server's certificate with the pinned certificate.
3. Rejection: If the certificates do not match, the app terminates the connection.

• Known weaknesses: Many tools and Frida scripts exist for bypassing certificate pinning. Some can be used with very limited technical knowledge.

To increase the resilience of certificate pinning, you should consider using runtime application self protection (RASP) features such as anti-hooking and anti-tampering.

• Against MITM: Certificate pinning is an effective defense against MitM attacks. An attacker will have to modify the application in order to intercept the traffic. On an unprotected app, this is easy to do, but it can become very complex if the RASP solution is robust enough.
• Against MATE: Certificate pinning has no impact, as the attacker is intercepting data before or after the TLS layer.
• Against bot farms: Whether it is a device-based or headless bot farm, the attacker acts as a regular client, so certificate pinning will not help.

mTLS

Mutual TLS (mTLS) provides mutual authentication, allowing your backend to verify the identity of the client application. In this scenario, we assume a shared client certificate model where the private key is embedded within the application itself. The backend identifies this single certificate to validate that requests are coming from your application rather than a generic browser or script.

While this doesn't identify individual users, it ensures that the client possesses the specific certificate distributed with your app. Additionally, if an attacker sets up a MITM proxy, the backend can detect that the communication does not originate from a valid application instance.

In mTLS, your app presents a client certificate during the TLS handshake. It is essentially certificate pinning in reverse:

• Certificate pinning: The application knows the backend's public key and rejects the connection if the server key is not pinned.
• mTLS (simplified): The backend knows the application's public key and rejects the connection if the client key is not trusted.

1. Client private key: The application stores the client's private key within its code.
2. Validation: During the TLS handshake, the app proves its identity using its private key.
3. Rejection: If the backend does not trust the client's private key, it rejects the connection.

• Extracting the client's private key: An attacker can extract the client's private key from the application code. They can then use it in their MITM proxy or to impersonate the app (as demonstrated in this blog post).
• No protection against tampering: mTLS does not guarantee that your application has not been tampered with. If an attacker modifies your application logic, the tampered version will still use the same private key and will therefore still be trusted by the backend.

In this scenario, mTLS relies on a client secret, making its protection crucial. First, you should use multiple layers of obfuscation and encryption to harden the code. Additionally, you should use RASP to prevent secret recovery via hooking, debugging, or tampering.

But even with these protections, you must assume that any static secret will eventually be extracted. Therefore, you should implement a rotation mechanism for the client's private key, such as changing it with each new release.

Impact on attacks:

• Against MITM: mTLS is an effective defense against MITM attacks. An attacker will have to extract the client's private key and use it in their MITM proxy. On an unprotected app, this is easy to do. If the application is sufficiently obfuscated and protected with RASP, the extraction process becomes more complex. However, because mTLS relies on a shared static secret, it is generally easier to bypass than certificate pinning.
• Against MATE: mTLS has no impact, as the attacker is intercepting data before or after the TLS layer.
• Against device-based bot farms: The attacker is using the regular application, so mTLS will not help.
• Against headless bot farms: mTLS provides good protection as long as the attacker cannot obtain the shared static secret. The level of security depends on the quality of code obfuscation and RASP protections. Once the secret is extracted, mTLS can be fully bypassed.

Application attestation

App attestation is a form of API security that can prevent backend abuses, including bot and script attacks. App attestation verifies that a request originated from an untampered app on a known-good device (e.g., not rooted, jailbroken, or running in an emulator).

How it works:

• Data gathering: The app gathers runtime metadata (e.g., hardware integrity, software state) and sends it to an attestation server.
• Token generation: The attestation server returns a signed token that only your backend can validate.
• Token usage: When your app makes a request to your backend, it includes the attestation token.
• Decision: Your backend verifies the token; if it is invalid, the request is rejected.

Security considerations:

Various application attestation solutions exist (e.g., Guardsquare, Google Play Integrity API, Apple AppAttest). The level of security provided depends on the solution you choose and how you configure it.

• Against MITM: By itself, app attestation does not prevent MITM attacks. However, some attestation solutions (such as Guardsquare's) allow binding the token to a specific request. In this case, app attestation can detect if the request has been intercepted or modified.
• Against MATE: App attestation will detect that the application has been tampered with, thereby identifying many MATE attacks.
• Against device-based bot farms: A good app attestation solution can detect if the application is running on a suspicious device or if the user interaction is not human. This information is integrated into the attestation token, allowing your backend to block these connections.
• Against headless bot farms: Even if an attacker fully reverse-engineers your communication layer, they will not be able to generate a valid attestation token. Thus, your backend can reject the connection due to the missing or invalid token.

Choosing your defense strategy

The following table summarizes the effectiveness of each protection mechanism against the attack targeting the communication layer, including:

• Does it protect against the attack scenario (✅/ ❌)
• Resilience score from ⭐ to ⭐⭐⭐⭐⭐ (to rate how easy/hard it is for an attacker to bypass the protection)

*Assumes token is bound to the specific request.

**Protected until the static client certificate is extracted.

Security is rarely a one-size-fits-all solution. The correct choice should be determined by your specific risk profile and potential business impact. The following level definitions can help guide your decision.

• Baseline level (Standard TLS): Suitable for low-risk applications where data is public or the impact of a breach is minimal. It protects against passive sniffing but offers no resistance to active attackers or automation.
• Intermediate level (Pinning + RASP): The minimum standard for any professional app handling PII or sensitive data. By moving beyond system-level trust, you effectively block "script kiddies" and basic reverse engineers using off-the-shelf tools. Pinning without RASP is not really recommended; you will have to face potential stability issues linked to pinning without having a real security benefit. Optionally, you can also add mTLS to provide entry-level protection against headless bot farms.
• Advanced level (Pinning + App Attestation): Essential for applications where automation or tampering poses a direct threat to the business model (e.g., financial services, e-commerce, or competitive gaming). This shifts the burden of proof to the client, ensuring that your backend only responds to untampered apps on legitimate hardware.

Guardsquare can help you identify and address the required level of communication layer security for your mobile applications. To schedule a consultation, contact us today.

Addendum: Don’t forget server-side protection

While this post focuses on protecting the communication layer from the client side, a robust security posture also requires server-side defenses. Although not the primary focus of this discussion, we recommend implementing the following measures to mitigate the impact of bot farms:

• Rate limiting and quotas: Limit the number of requests per IP, user, or API key to prevent brute-force attacks and resource exhaustion.
• IP reputation and geo-fencing: Block or challenge traffic from known malicious IP ranges, data centers, or geographic regions that are not part of your target market.
• Web application firewall (WAF): Use a WAF to detect and block common bot patterns, scrapers, and automated scripts based on fingerprinting and behavioral analysis.

Combining these server-side protection layers with the aforementioned mobile-specific defenses provides the most effective defense against automated threats.