Welcome to the fifth article in our OWASP Mobile Top 10 2024 series! In previous articles we covered M1: Improper Credential Usage, M2: Inadequate Supply Chain Security, M3: Insecure Authentication/Authorization, and M4: Insufficient Input/Output Validation. Today we discuss why "we already use HTTPS" isn't a sufficient answer.
M5 is the most misleading item on the list, because most teams read it and move on: "We use HTTPS, this doesn't apply to us."
OWASP's definition is far broader. This risk covers all aspects of getting data from point A to point B, but doing it insecurely. It encompasses mobile-to-mobile communications, app-to-server communications, or mobile-to-something-else communications. It includes all communications technologies that a mobile device might use: TCP/IP, WiFi, Bluetooth/Bluetooth-LE, NFC, audio, infrared, GSM, 3G, SMS, etc.
So M5 isn't just "do you use HTTPS." It's all of this: Whether you set up TLS correctly (certificate checking, cipher selection) Whether your traffic is consistent (some endpoints HTTPS, others not) What your third-party SDKs are doing What your WebView is loading What you send over alternate channels like push notifications and SMS
💡 Key point: Just because an app uses transport security protocols doesn't mean it's implemented correctly. HTTPS is not a checkbox; it's a system that must be configured properly.
In React Native the network layer lives in three separate places, and most developers only think about the first: The JavaScript side — fetch, axios, XMLHttpRequest Platform configuration — ATS on iOS, Network Security Config on Android Native modules and SDKs — analytics, ads, crash reporting, payment SDKs
Whatever you do on the JavaScript side, if platform configuration is loose or a third-party SDK uses plaintext HTTP, your app is exposed.
| Metric | Value | Meaning | |--------|-------|---------| | Exploitability | EASY | A proxy and the same network is enough | | Prevalence | COMMON | Very frequently found in applications | | Detectability | AVERAGE | Basic flaws are easy, subtle ones are not | | Technical Impact | SEVERE | Account takeover, impersonation | | Business Impact | MODERATE | Privacy violation, reputational damage |
⚠️ Compare with M4: M4's exploitability was DIFFICULT; M5's is EASY. Exploiting this doesn't require Frida, reverse engineering, or a custom exploit. Being on the same café Wi-Fi as the victim and setting up a proxy is enough.
To identify basic flaws, you can observe the network traffic on the phone. However, detecting more subtle flaws requires a closer look at the application's design and configuration.
✅ In scope TLS setup and validation failures Weak cipher suites Accepting invalid certificates Plaintext (HTTP) traffic Bluetooth, NFC, WiFi Direct security Sensitive data over SMS/MMS Sensitive data in push notification payloads Mixed SSL sessions
❌ Out of scope Data stored on the device → M9: Insecure Data Storage Weak/predictable session ID, when the channel is secure → M3: Insecure Authentication Weak encryption algorithm outside of transport → M10: Insufficient Cryptography
If the data is being stored locally in the device itself, that's Insecure Data. If the session details are communicated securely (e.g., via a strong TLS connection) but the session identifier itself is bad (perhaps it is predictable, low entropy, etc.), then that's an Insecure Authentication problem, not a communication problem.
The usual risks of insecure communication are around data integrity, data confidentiality, and origin integrity.
| Risk | Question | Example violation | |------|----------|-------------------| | Confidentiality | Can someone else read it? | Plaintext HTTP, weak cipher | | Integrity | Can it be changed in transit? | Response manipulation via MITM | | Origin integrity | Is the other side really who it claims? | Certificate not validated |
If the data can be changed while in transit, without the change being detectable (e.g., via a man-in-the-middle attack) then that is a good example of this risk. If confidential data can be exposed, learned, or derived by observing the communications as it happens (i.e., eavesdropping) or by recording the conversation as it happens and attacking it later (offline attack), that's also an insecure communication problem.
Most modern mobile applications exchange data with one or more remote servers. When the data transmission takes place, it typically goes through the mobile device's carrier network and the internet; a threat agent listening on the wire can intercept and modify the data if it is transmitted in plaintext or using a deprecated encryption protocol.
📡 An adversary sharing your local network (compromised or monitored Wi-Fi) Café, hotel, airport Wi-Fi Rogue access point ("FreeAirportWiFi") MITM on the same network via ARP spoofing