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 network communication that remains readable in transit because it is not encrypted. The defining issue is not just that the data travels unprotected, but that any observer on the path can read or alter it before it reaches the destination.
That makes cleartext a transport-layer security problem, not merely a format choice. HTTP instead of HTTPS, or any equivalent unencrypted channel, creates a path where confidentiality and integrity both depend on the surrounding network being trusted, which is rarely a safe assumption.
Why Cleartext Traffic Is Dangerous
Cleartext creates immediate exposure for anything sensitive that crosses the wire, including credentials, session material, API tokens, personal data, and application state. It also creates an opportunity for tampering, so the risk is not limited to passive eavesdropping.
Where applications send login requests, bearer tokens, or device telemetry in cleartext, an attacker with network visibility can capture usable secrets or modify requests and responses in transit. The risk is especially high on shared Wi-Fi, hostile networks, misconfigured proxies, and mobile clients that roam across untrusted access networks.
For broader control context, transport protection is a standard expectation in NIST SP 800-53 Rev 5 Security and Privacy Controls, and NIST Cybersecurity Framework 2.0 frames it as part of protecting data and communications.
Where Cleartext Traffic Commonly Appears
Cleartext often shows up in legacy systems, temporary integrations, internal service calls, diagnostic endpoints, and development or testing environments that were never hardened for production use. It can also appear in mobile and embedded software when developers leave exceptions in place for specific hosts or protocols.
That pattern matters because “internal only” is not the same as safe. Internal traffic can still be intercepted by compromised hosts, rogue access points, malicious proxies, or an attacker who has already gained a foothold inside the environment.
In cloud and service-heavy architectures, insecure transport can become part of a larger trust failure. Techniques described in NIST Privacy Framework and hardening guidance such as CIS Benchmarks help reduce the chance that insecure defaults persist unnoticed.
How Organizations Should Treat It
Cleartext should be treated as a deliberate exception, not an acceptable default. If a system must allow it for a tightly scoped reason, the exception should be narrowly bounded, documented, and monitored so it cannot quietly spread into more sensitive flows.
In mobile app environments, this often means allowing cleartext only for a specific destination during migration or compatibility work, while keeping all other endpoints encrypted. The same principle applies to APIs and backend services: if the data matters enough to protect, the transport path usually should too.
For engineering and verification work, controls in OWASP SAMM and build integrity discipline from SLSA support the broader habit of preventing insecure defaults from entering production.
Risk and Threat Considerations
Cleartext traffic expands the attack surface because any actor positioned on the network path can read, replay, or alter traffic without needing to break encryption. In practice, that makes it a common enabler for credential theft, session hijacking, request tampering, and downgrade abuse.
Failure mechanism: The communication path lacks confidentiality and integrity protections, so interception tools, malicious access points, transparent proxies, or compromised intermediate systems can observe or modify traffic in transit.
Impact: Attackers can steal secrets, impersonate users or services, manipulate application behaviour, and pivot from one exposed request into broader account or data compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-8 — Transmission Confidentiality and Integrity | Directly addresses protecting data in transit, which cleartext traffic lacks. |
| SC-13 — Cryptographic Protection | Covers use of cryptography to protect communications and stored data relevant to cleartext exposure. | |
| IA-5 — Authenticator Management | Cleartext traffic can expose authenticators and tokens that this control is meant to protect. | |
| Recommendation — Require protected channels for sensitive traffic and eliminate unencrypted transport where confidentiality or integrity matters. Apply cryptographic protection to network exchanges carrying secrets or sensitive data. Prevent authenticators and tokens from traversing unprotected channels and rotate any exposed secrets immediately. | ||
| NIST CSF 2.0 | PR.DS-02 — Data-in-Transit is Protected | Cleartext traffic is the direct opposite of protected data in transit. |
| PR.AA-05 — Authenticator Management | Cleartext can expose credentials and session material, undermining identity protection. | |
| Recommendation — Encrypt data in transit and remove exceptions that leave sensitive communications readable on the wire. Treat exposed credentials as compromised and enforce protected transport for authentication exchanges. | ||
| CIS Controls v8 | CIS-13 — Network Monitoring and Defense | Cleartext is often detected and constrained through network monitoring and segmentation controls. |
| CIS-4 — Secure Configuration of Enterprise Assets and Software | Cleartext commonly persists because insecure protocol defaults and exceptions are left enabled. | |
| Recommendation — Monitor for unencrypted sensitive traffic and block it at trusted network boundaries. Harden clients and services so insecure transport is disabled by default and exceptions are tightly controlled. | ||
| OWASP ASVS | V12 — Secure Communication | The term maps directly to application communication security and transport protection. |
| V14 — Data Protection | Cleartext traffic exposes sensitive data that ASVS expects to protect during transmission. | |
| Recommendation — Enforce encrypted transport for application traffic and reject cleartext for sensitive exchanges. Classify sensitive data paths and ensure they never traverse unprotected links. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Cleartext often results from insecure transport configuration in APIs and service endpoints. |
| Recommendation — Configure APIs to require TLS and eliminate plaintext endpoints that expose secrets or payloads. | ||
Practitioner Guidance
What to watch for: Prioritize any traffic that carries authentication material, session identifiers, personal data, or privileged commands. If a cleartext exception exists, treat it as a monitored risk decision rather than a benign compatibility setting.
Practitioner takeaway: The safest default is encrypted transport everywhere, with cleartext allowed only when you can name the exception, constrain the destination, and justify the exposure.
Related resources from NHI Mgmt Group
- 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?
- What is the difference between routing traffic and governing identity at the edge?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
