HTTP/2 traffic sent without TLS encryption, often called h2c. It is unusual on internet-facing services because most clients and browsers use HTTP/2 only over TLS, so its appearance can indicate a downgrade path, misconfiguration, or failing security control.
What Cleartext HTTP/2 Means
Cleartext HTTP/2, often called h2c, is HTTP/2 carried without TLS encryption. That makes the protocol visible in transit, which is unusual on public services and immediately changes the trust assumptions around confidentiality, integrity, and endpoint authenticity.
In practice, h2c is most often seen where HTTP/2 is used on trusted internal networks, in controlled test environments, or behind gateways that terminate encryption elsewhere. On the open internet, it is more of a red flag than a normal deployment choice.
Why Cleartext HTTP/2 Is Operationally Unusual
Most browsers and internet-facing clients negotiate HTTP/2 over TLS, so cleartext HTTP/2 usually means the service is outside the normal secure browser path. That matters because many security controls, including interception resistance, certificate validation, and encrypted transport assumptions, are bypassed or absent.
Its presence can indicate a deliberate design choice, but it can also reveal an accidental downgrade path or an internal-only service exposed beyond its intended boundary. When that happens, the issue is not just transport format, it is a mismatch between how the service is configured and how it is reachable.
Security Implications of Using h2c
Without TLS, traffic can be read or altered by any intermediary with network access. That creates exposure for credentials, session material, API requests, and responses if the application carries sensitive data over the connection.
Cleartext HTTP/2 also weakens confidence in server identity because the client is not relying on certificate-based authentication. If the deployment expects authenticated peers, encrypted transport is part of the trust boundary, not an optional enhancement.
How Teams Validate and Contain Exposure
Teams should confirm whether h2c is intentionally used, where it is allowed, and whether any exposed listener is reachable from untrusted networks. The most reliable checks are an asset inventory, configuration review, packet inspection, and comparison with vendor deployment guidance for the exact service.
If cleartext HTTP/2 is only supposed to exist behind a reverse proxy or inside a private segment, then exposure should be treated as a boundary failure. A conservative operational stance is to prefer encrypted transport everywhere the service can be reached by users, clients, or other systems outside a tightly controlled trust zone.
Risk and Threat Considerations
Cleartext HTTP/2 creates a straightforward interception and tampering risk when it crosses networks that are not fully trusted. It can also expose a hidden downgrade path, where a service intended to negotiate secure HTTP/2 silently falls back to an unencrypted mode.
Failure mechanism: A misconfigured listener, proxy, or service endpoint accepts h2c where encrypted HTTP/2 was expected, allowing traffic disclosure, request manipulation, or credential capture on the path.
Impact: Attackers or intermediaries can observe or modify application traffic, which may compromise secrets, sessions, API calls, and downstream trust decisions made by the application or adjacent controls.
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 and NIST CSF 2.0 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 | h2c removes transport protection for HTTP/2 traffic |
| AC-4 — Information Flow Enforcement | Cleartext HTTP/2 can cross trust boundaries without enforced policy | |
| Recommendation — Require protected transmission for sensitive HTTP/2 traffic and block cleartext paths where encryption is expected. Enforce flow policy so unencrypted HTTP/2 cannot traverse unapproved network boundaries. | ||
| NIST CSF 2.0 | PR.DS-02 — Data in Transit Is Protected | Cleartext HTTP/2 is unprotected data in transit |
| PR.AA-05 — Identity and Access Management | Transport security supports trusted access to services over HTTP/2 | |
| Recommendation — Protect HTTP/2 traffic in transit wherever confidentiality or integrity matters. Use authenticated, encrypted channels for service access paths that carry sensitive requests. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Cleartext HTTP/2 concerns whether cryptographic protection is applied in transit |
| Recommendation — Mandate cryptographic protection for service traffic where confidentiality or integrity is required. | ||
Practitioner Guidance
Why practitioners should care: Treat h2c as a deployment decision that must be explicitly justified, not as a benign protocol variant. If the service is internet-facing or carries sensitive data, cleartext transport usually signals a control gap that deserves review.
What to watch for: Look for unexpected cleartext listeners, reverse-proxy rules that permit downgrade, and services that behave differently in internal versus external environments. If the service is meant to support authentication, API traffic, or user sessions, verify that transport protection matches that expectation.
For protocol-specific transport and authorization guidance, the Model Context Protocol: Authorization specification shows how modern HTTP transports are expected to preserve strong access boundaries, while the NIST SP 800-53 Rev 5 Security and Privacy Controls and NIST Cybersecurity Framework 2.0 provide the broader control lens for secure communications, configuration, and monitoring.