A man-in-the-middle attack is what most of mobile transport security is designed to prevent: an attacker sitting between your app and your server, reading or changing the traffic as it passes. It happens on hostile Wi-Fi, through a malicious proxy, or via a certificate the attacker controls, and it succeeds when an app sends data in cleartext or fails to validate the server's certificate. The defenses are mostly about getting HTTPS and certificate validation right, with pinning as an extra layer for high-value apps. Here is what a MITM attack is, how it happens on mobile, and how to defend against it.
Short answer
A man-in-the-middle (MITM) attack is when an attacker intercepts the communication between your app and your server, allowing them to read or modify the traffic. Per OWASP MASVS, it succeeds when an app uses cleartext HTTP or fails to properly validate the server's TLS certificate, and it is staged through hostile Wi-Fi, a malicious proxy, or a certificate the attacker controls. The defense is to use HTTPS everywhere with no cleartext, never disable or weaken certificate validation, rely on App Transport Security on iOS and the network security config on Android, and consider certificate pinning for high-value apps. Sound transport security is what closes the door on MITM.
What you should know
- MITM intercepts your traffic: the attacker reads or modifies it in transit.
- Cleartext enables it: plain HTTP can be read and changed.
- Weak cert validation enables it: accepting any certificate defeats HTTPS.
- It is staged on the network: hostile Wi-Fi, proxies, attacker certificates.
- HTTPS done right defends it: no cleartext, proper validation, optional pinning.
What is a man-in-the-middle attack?
It is an attacker positioning themselves between your app and the server it talks to, so the traffic flows through them. From that position they can read the data, your users' credentials, tokens, and personal information, and they can modify it, altering responses or injecting content. The attack does not require breaking into your server or the user's device; it only requires being on the path between them, which happens more easily than people assume on shared or hostile networks. MITM is the threat that HTTPS exists to stop, because properly validated TLS encrypts the traffic and proves the server's identity, so an interceptor cannot read or impersonate it. The attack therefore succeeds specifically when that protection is missing or weakened, which is what the defenses address.
How does MITM happen on mobile?
Through the network and through certificate weaknesses. The table lists the common vectors.
| Vector | How it enables interception |
|---|---|
| Hostile or open Wi-Fi | The attacker controls the network path |
| Malicious proxy | Traffic is routed through the attacker |
| Cleartext HTTP | Data is unencrypted and readable as-is |
| Accepting any certificate | Disabled validation lets the attacker impersonate the server |
| Rogue or user-installed CA | A certificate the attacker controls is trusted |
The two app-side enablers are the ones you control: sending traffic in cleartext, which needs no certificate trickery to read, and failing to validate the server's certificate, for example by disabling validation during development and shipping it, which lets the attacker present their own certificate and impersonate your server. The network vectors, hostile Wi-Fi and proxies, are how the attacker gets in position, but a properly secured connection resists them.
How do you defend against it?
Use HTTPS everywhere and validate certificates properly, then add pinning if warranted. The foundation is to send all traffic over HTTPS with no cleartext, so there is nothing readable in transit, and to keep certificate validation in force, never accepting arbitrary certificates or disabling validation, even temporarily, in a build that could ship. Use App Transport Security on iOS and the network security config on Android to enforce secure connections, and for sensitive apps consider certificate pinning, which restricts trust to your server's specific certificate or key so even a rogue trusted CA cannot impersonate you, accepting its operational cost. For high-sensitivity apps, you can also choose not to trust user-installed CAs. The throughline is that MITM exploits missing or weak transport security, so getting HTTPS and validation right, and not weakening them for convenience, is what defends against it.
What to watch out for
The first trap is shipping cleartext HTTP, which an interceptor can read directly; use HTTPS everywhere. The second is disabling or weakening certificate validation, often a development shortcut left in, which lets an attacker present their own certificate; never ship that. The third is assuming HTTPS alone is enough for a high-value app on hostile networks, where pinning adds protection against rogue CAs. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK, AAB, or IPA against OWASP MASVS and surfaces cleartext traffic and transport configuration, so you can confirm your app is not exposed to MITM before you ship. The transport settings you fix in the app.
What to take away
- A man-in-the-middle attack intercepts the traffic between your app and server, letting an attacker read or modify it.
- It succeeds when the app uses cleartext or fails to validate certificates, and it is staged through hostile Wi-Fi, proxies, or attacker-controlled certificates.
- Defend with HTTPS everywhere, proper certificate validation that you never weaken, App Transport Security and the network security config, and certificate pinning for high-value apps.
- Use a pre-submission scan such as PTKD.com to confirm there is no cleartext or weak transport configuration that would expose you to MITM.
