Network traffic sent without encryption, such as HTTP instead of HTTPS. In mobile apps, cleartext can expose credentials, tokens, and sensitive application data to interception or tampering. Android network security settings can block it globally or allow it only for tightly scoped destinations when unavoidable.
What Cleartext Traffic Means in Practice
Cleartext traffic is unencrypted network communication, so anyone positioned to observe or alter the traffic can read it directly. The core issue is not just confidentiality loss, but the absence of transport protection, which leaves requests, responses and protocol metadata exposed to interception, tampering and replay-style abuse.
Why Cleartext Traffic Is Dangerous
When a protocol remains in cleartext, the network path becomes part of the trust boundary. That matters most when traffic carries login material, session artefacts, API payloads or sensitive business data. In application environments, cleartext also widens the attack surface for man-in-the-middle interception, downgrade abuse and content modification in transit.
For mobile and distributed systems, the risk is often practical rather than theoretical, because clients may connect over untrusted Wi-Fi, consumer broadband, proxy infrastructure or hostile local networks. If the application accepts cleartext on even a small set of endpoints, those paths can become the easiest place to harvest data or manipulate requests.
Where Cleartext Traffic Shows Up
Cleartext is most visible in legacy HTTP usage, but it also appears in internal service calls, test or debug configurations, misconfigured mobile network security settings and third-party integrations that still rely on plaintext transport. Developers sometimes treat it as acceptable only for non-sensitive data, yet even “low-risk” payloads can reveal identifiers, device context, API structure or navigation paths that help an attacker build a broader picture.
In mobile applications, platform controls can help constrain this behaviour. Android network security settings can block cleartext globally or allow it only for tightly scoped destinations when there is a documented operational need. That makes policy explicit, rather than leaving plaintext use to code defaults or ad hoc exceptions.
How Organisations Reduce Exposure
Reducing cleartext exposure starts with inventory, because teams need to know which applications, APIs, services and devices still emit plaintext traffic. That inventory should be checked against internet exposure, internal routing paths and vendor or partner integrations, since a supposedly internal flow may still traverse shared infrastructure or unsecured segments. Where cleartext is unavoidable, organisations should narrow it to the smallest possible scope and document the exception.
Transport hardening should then be paired with configuration review, dependency review and validation of client behaviour. If an application supports encryption, teams should verify that users and services actually negotiate it by default, rather than silently falling back to plaintext. For Android apps, a secure network configuration can prevent accidental regressions when libraries, SDKs or feature changes reintroduce cleartext.
Detection, Remediation and Post-Exposure Review
Cleartext traffic is detectable through packet inspection, proxy logs, endpoint telemetry and application-side logging that records protocol use or failed handshake attempts. If exposure is discovered after deployment, the immediate question is whether secrets, sessions or sensitive payloads may already have traversed the unencrypted path. If so, the review should include whether credentials, tokens or other application secrets need rotation or invalidation.
Remediation is usually straightforward in principle, but deployment realities matter. Teams may need to stage TLS enablement, update certificates, fix hard-coded endpoints, or temporarily compensate with network segmentation and strict routing controls while the final encrypted path is being restored. The objective is to remove the plaintext dependency without creating a larger outage or pushing teams to re-enable it permanently as a workaround.
Risk and Threat Considerations
Cleartext traffic is attractive to attackers because it turns ordinary network visibility into a data source. Once plaintext is present, interception can expose credentials or tokens, and modification in transit can alter requests or responses without needing to break encryption. That makes the risk especially acute for authentication flows, mobile app traffic and API calls carrying sensitive data.
Failure mechanism: The failure is loss of transport confidentiality and integrity, which allows passive capture or active tampering anywhere the traffic crosses an untrusted network path.
Impact: Exposure can lead to account compromise, session theft, data leakage, request manipulation and broader trust collapse in the affected application or service path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-8 — Transmission Confidentiality and Integrity | Cleartext traffic directly concerns protection of data in transit. |
| SC-13 — Cryptographic Protection | Encrypting traffic is the primary control that removes cleartext exposure. | |
| Recommendation — Require protected communications to preserve confidentiality and integrity across network paths. Apply cryptographic protection to networked data before it leaves trusted boundaries. | ||
| OWASP ASVS | V12 — Secure Communication | ASVS directly addresses secure transport and rejection of plaintext communication paths. |
| Recommendation — Verify that sensitive application traffic uses secure transport and does not fall back to cleartext. | ||
| CIS Controls v8 | CIS-3 — Data Protection | Cleartext traffic is a data protection failure because it exposes information in transit. |
| Recommendation — Protect data in transit with encryption and restrict plaintext exposure to documented exceptions. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | The term maps to cryptographic protection of information in transit. |
| Recommendation — Use cryptography to prevent plaintext transmission of sensitive information. | ||
Practitioner Guidance
Why practitioners should care: Treat cleartext as a configuration and architecture control issue, not just a coding preference. A single plaintext exception can undermine otherwise strong authentication or authorisation if secrets or session material are still carried in transit.
What to watch for: Look for fallback behaviour, legacy endpoints, partner integrations, mobile debug profiles and platform settings that silently permit plaintext. The most dangerous cases are the ones that remain functional, because they tend to survive long after teams believe encryption is “already enabled”.
Practitioner takeaway: Enforce encrypted transport by default, allow cleartext only by exception, and treat any observed plaintext path as a candidate for immediate review.
Related resources from NHI Mgmt Group
- What breaks when authentication traffic falls back to cleartext on a trusted port?
- When should organisations block anonymous network traffic at login?
- How should teams rotate JWT signing keys without breaking production traffic?
- What is the difference between securing V2X traffic and securing automotive identities?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org