A mobile app talks to servers constantly, for login, data, payments, sync, and every one of those exchanges crosses a network the app does not control: cafe Wi-Fi, a carrier, a corporate proxy. If that communication is not properly protected, an attacker positioned on the network can read it, alter it, or impersonate the server. That is the risk OWASP captures as M5, Insecure Communication, in its Mobile Top 10. It is not one bug but a category covering missing encryption, weak transport settings, and failure to verify who the app is really talking to. Here is what M5 is and how to address it.
Short answer
M5, Insecure Communication, is the OWASP Mobile Top 10 risk covering how an app transmits data over the network. Per OWASP, the risk is that data sent without proper protection, no encryption, weak or misconfigured TLS, or without verifying the server's certificate, can be read or altered by an attacker on the network, a man-in-the-middle. The defenses are to use TLS for all communication including to every endpoint and SDK, validate certificates properly and never disable validation, use modern TLS configurations, avoid sending sensitive data over insecure channels, and for high-value connections consider certificate pinning. The principle is that every byte the app sends should travel encrypted to a server whose identity has been verified.
What you should know
- M5 is about data in transit: how the app communicates over the network.
- The threat is a network attacker: reading or altering traffic in the middle.
- Use TLS everywhere: for every endpoint, including those reached by SDKs.
- Validate certificates: never disable or weaken certificate checking.
- Pin for high-value connections: certificate pinning where the risk warrants.
What is M5: Insecure Communication?
It is the risk that an app's network communication is not adequately protected. When an app sends or receives data, that traffic travels over networks controlled by others, and an attacker positioned in the path, on shared Wi-Fi, a compromised router, a hostile network, can intercept it, a man-in-the-middle. If the communication is in cleartext, the attacker reads it; if encryption is present but weak or misconfigured, it may be breakable; and if the app does not verify the server's certificate, the attacker can impersonate the server and the app will not notice. M5 covers all of these: missing transport encryption, weak TLS settings, accepting invalid or untrusted certificates, and sending sensitive data over channels that are not secure. It treats the confidentiality and integrity of data in transit, and the authenticity of the server, as the asset to protect, which is foundational because almost everything else an app does depends on its network exchanges being trustworthy.
How does communication become insecure?
In a handful of recurring ways. The table lists them.
| Failure | What it looks like |
|---|---|
| No encryption | Cleartext traffic an attacker can read |
| Weak TLS | Outdated protocol versions or weak ciphers |
| Skipped validation | Accepting invalid or untrusted certificates |
| Insecure channels | Sensitive data sent over non-secure paths |
| Unprotected SDK traffic | Third-party libraries communicating insecurely |
The most basic failure is no encryption, sending traffic in cleartext where anyone on the path can read it. Beyond that, encryption can be present but weak, using outdated TLS versions or weak ciphers that do not hold up. A subtler and dangerous failure is skipping certificate validation, disabling it or accepting any certificate, often left in from development, which lets an attacker present their own certificate and intercept the supposedly encrypted traffic. Sensitive data sent over channels that are not secure, and traffic from third-party SDKs that communicate insecurely without your noticing, round out the category. Each leaves data in transit exposed to a network attacker.
How do you address M5?
Encrypt everything, verify the server, and keep configurations strong. Use TLS for all network communication, with no cleartext exceptions, and make sure that applies to every endpoint your app and its SDKs contact, not just your main API. Validate certificates properly and never disable certificate validation or accept arbitrary certificates, since that single shortcut undoes the encryption, treating any such code left from development as a release blocker. Use modern TLS protocol versions and strong ciphers, relying on the platform's secure defaults rather than weakening them. For high-value connections, where the data or the threat justifies it, consider certificate pinning so the app only trusts your specific certificate, while planning for rotation so pinning does not break the app. Avoid sending sensitive data over channels that are not secure. And confirm that third-party SDKs communicate securely, since their traffic is your app's traffic to a user. The principle is that data in transit is always encrypted and the server is always verified, with no exceptions slipped in for convenience.
What to watch out for
The first trap is disabled or weakened certificate validation, often a development shortcut that ships, which silently defeats TLS; treat it as a release blocker. The second is cleartext traffic or weak TLS to some endpoint, frequently one reached by an SDK rather than your own code. The third is assuming TLS alone is enough for the highest-value connections, where pinning adds protection. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled app against OWASP MASVS and surfaces the endpoints it contacts and whether it uses secure transport, flagging cleartext and weakened validation, which is exactly the M5 surface to clean up before release.
What to take away
- M5, Insecure Communication, is the OWASP Mobile Top 10 risk about protecting data in transit against a network attacker who could read, alter, or impersonate.
- Communication becomes insecure through no encryption, weak TLS, skipped certificate validation, insecure channels, or unprotected SDK traffic.
- Address it by using TLS everywhere, validating certificates and never disabling validation, keeping TLS configurations modern, pinning high-value connections, and confirming SDKs communicate securely.
- Use a pre-submission scan such as PTKD.com to surface cleartext traffic, weak transport, and weakened validation across the endpoints your app contacts.
