MITM Attacks in Mobile Apps — What They Are, Types and Protection from Interception

What Is a MITM Attack?

Man-in-the-Middle (MITM) is a type of cyber attack where an attacker secretly inserts themselves into a communication channel between two parties. The attacker can intercept, read, and modify transmitted data while remaining invisible to both parties.

In mobile apps, MITM attacks are especially dangerous because devices constantly connect to various networks — home, office, public Wi-Fi in cafes and airports. Each network switch potentially creates a window for attack. According to Verizon Mobile Security Index (2025), 43% of organizations have encountered MITM attacks on corporate mobile devices at least once.

The main danger of MITM is stealth: the user and server receive no signals of interception. The session looks normal, data is transmitted, there are no certificate errors (if the attacker uses their own certificate). The attack can only be detected at the network infrastructure level or using specialized tools.

A developer needs to understand MITM attack mechanisms in order to design protection at the application level, rather than relying solely on transport layer security.

Main Types of MITM Attacks

The classification of MITM attacks includes several types that differ in the method of insertion into the communication channel. In mobile development, three types are most relevant.

ARP Spoofing on the Local Network

ARP Spoofing is a technique where the attacker sends fake ARP packets to the local network, associating their MAC address with the gateway IP address. After this, all the victim’s traffic is routed through the attacker’s device, who forwards it to the gateway while remaining invisible.

Tools like Ettercap or BetterCAP are sufficient to carry out the attack, as they automate ARP spoofing. The attack is only possible within a single subnet, making users of public Wi-Fi networks the most vulnerable. Modern networks with Dynamic ARP Inspection (DAI) on managed switches block this type of attack.

Protection at the application level from ARP Spoofing is impossible — this is a network infrastructure issue. However, the application can detect anomalies in network connectivity using libraries like TrustKit for iOS or Network Security Config for Android.

DNS Spoofing and Traffic Interception

DNS Spoofing (or DNS Cache Poisoning) is the substitution of DNS records along the path from the client to the DNS server. The attacker intercepts the application’s DNS request and returns a fake IP address, redirecting traffic to their server instead of the legitimate one.

The attack is especially effective in public networks where the DNS server is assigned automatically via DHCP. The attacker can set up their own DNS server that returns spoofed IP addresses for target domains. The user sees a legitimate URL in the browser but connects to the attacker’s server.

Protection from DNS Spoofing at the application side is implemented through DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT), which encrypt DNS queries. Android 9+ and iOS 14+ support system-level DoH, and the application can explicitly enable this option.

SSL Stripping — Bypassing HTTPS

SSL Stripping is an attack where the attacker downgrades a secure HTTPS connection to unsecured HTTP. The technique exploits the fact that many users manually type example.com instead of https://example.com, and the first connection is established via HTTP.

Tools like sslstrip (Moxie Marlinspike, 2009) and bettercap automatically intercept HTTP requests, establish an HTTPS connection with the server on their behalf, and pass decrypted traffic to the client via HTTP. The browser does not show the padlock icon — the user does not know the connection is not secure.

Modern protection — HTTP Strict Transport Security (HSTS): the server informs the browser that all future connections must only use HTTPS. The HSTS Preload List additionally protects against the first attack but requires prior domain registration.

How a MITM Attack Works in Mobile Apps

A typical MITM attack on a mobile app goes through four stages. Each stage exploits different vulnerabilities, and full protection requires covering all vectors.

The first stage is insertion: the attacker gets in the path of traffic between the device and the server. This can be ARP Spoofing on the local network, a fake Wi-Fi access point (Evil Twin), or compromise of the provider’s DNS server. Mobile devices are especially vulnerable when automatically connecting to open networks.

The second stage is interception: after insertion, the attacker starts reading all packets exchanged between the app and the server. At this stage, they collect metadata: request URLs, packet sizes, cookies, headers. Even if the data is encrypted, metadata can reveal the application structure and business logic.

The third stage is decryption (if traffic is encrypted): the attacker establishes two TLS connections — one with the server (using a spoofed certificate), another with the client. The app considers the connection secure, but the attacker sees all data in plaintext. Without Certificate Pinning, this works for any certificate installed in the system store.

The fourth stage is modification and exfiltration: the attacker can not only read but also modify the transmitted data. In financial apps, this could mean changing the recipient’s account number; in API requests, modifying authorization parameters. iOS and Android recommend implementing response integrity checks at the application level.

Code Examples: Protection from Interception on Android and iOS

Let’s look at practical examples of protection against MITM attacks using Certificate Pinning in Kotlin and Swift. These examples block certificate substitution even if the system store is compromised.

Certificate Pinning on Android (OkHttp)

OkHttp is the standard HTTP library for Android that supports CertificatePinner. Specify the SHA-256 hash of your server’s certificate — any other certificates will be rejected.

import okhttp3.CertificatePinner
import okhttp3.OkHttpClient

val certificatePinner = CertificatePinner.Builder()
    .add(
        "api.example.com",
        "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="
    )
    .build()

val client = OkHttpClient.Builder()
    .certificatePinner(certificatePinner)
    .build()

Certificate Pinning on iOS (URLSession)

On iOS, use URLSessionDelegate to manually verify the server certificate. Compare the SecCertificateRef against a locally stored copy.

class SessionDelegate: NSObject, URLSessionDelegate {
    func urlSession(
        _ session: URLSession,
        didReceive challenge: URLAuthenticationChallenge,
        completionHandler: @escaping (
            URLSession.AuthChallengeDisposition,
            URLCredential?
        ) -> Void
    ) {
        guard let serverTrust = challenge.protectionSpace
            .serverTrust else { return }

        let pinnedCert = SecCertificateCreateWithData(
            nil,
            pinnedCertData as CFData
        )

        let serverCerts = (0..<SecTrustGetCertificateCount(serverTrust))
            .compactMap { SecTrustGetCertificateAtIndex(serverTrust, $0) }

        if serverCerts.contains { CFEqual($0, pinnedCert) } {
            completionHandler(.useCredential, URLCredential(trust: serverTrust))
        } else {
            completionHandler(.cancelAuthenticationChallenge, nil)
        }
    }
}

Network Security Config on Android

Android supports declarative protection through the network_security_config.xml file, which blocks traffic at the OS level without writing code.

<!-- network_security_config.xml -->
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-07-01">
            <pin digest="SHA-256">AAAAAAAAAAAAAAAAAAAAAAAAAAAA</pin>
        </pin-set>
    </domain-config>
</network-security-config>

Methods of Protecting Mobile Apps from MITM

Comprehensive protection against MITM attacks includes measures at the application, server, and network infrastructure levels. Below are the main recommendations for Android and iOS.

Use Certificate Pinning — binding the server certificate in the application code. Unlike standard TLS verification, which trusts any certificate from the system store, Certificate Pinning checks a specific certificate or its public key. OkHttp on Android and TrustKit on iOS provide ready-made implementations of this mechanism.

Enforce HTTPS and HSTS: all network requests must go through HTTPS, and the server should return the Strict-Transport-Security header. For Android, add android:usesCleartextTraffic="false" to the manifest — this blocks HTTP connections at the OS level. iOS blocks HTTP by default since iOS 9 through App Transport Security (ATS).

Implement response integrity checks: sign server responses with a digital signature that the app verifies. Even if an attacker intercepts HTTPS traffic (through a proxy with certificate reinstallation), they cannot forge the signature without the server’s private key. Use JWT with RS256 or HMAC signatures for critical operations.

On the server side, enable HTTP Public Key Pinning (HPKP) — a directive that tells the browser or app which certificate to consider valid for a given domain. However, HPKP requires caution: incorrect configuration can block access to the application for an extended period. Google recommends using HPKP only in combination with backup certificates.

According to NIST SP 800-52 Rev. 2 (2024), the combination of TLS 1.3, Certificate Pinning, and HSTS eliminates 99% of known MITM attack vectors on mobile apps. Developers are recommended to test protection using tools like mitmproxy before publishing the application.