A common warning sign is receiving a 101 Switching Protocols response, followed by no meaningful HTTP/2 behavior. Other indicators include inconsistent results across different paths, successful forwarding of Upgrade and Connection headers, and access control that disappears once the connection becomes a tunnel. Those patterns suggest the proxy is no longer enforcing content-aware policy.
How to tell when h2c upgrade handling is going wrong
The clearest signal is a proxy or back end that accepts the HTTP/1.1 upgrade request, returns 101 Switching Protocols, but then behaves like the connection never became a real HTTP/2 stream. You may also see one path upgrade cleanly while another falls back or stalls, which usually means the h2c handling is inconsistent across listeners, routes, or intermediaries.
A second sign is that the proxy forwards Upgrade and Connection headers correctly enough to trigger the switch, but loses normal HTTP-aware enforcement afterward. Once the connection is treated as a tunnel, request inspection, routing logic, and some access checks may disappear because the system is no longer applying policy at the message layer.
Another practical indicator is a mismatch between what the client asked for and what the server actually processes. If the client sends an h2c upgrade but the backend continues to answer only in HTTP/1.1 semantics, or the connection closes without any visible HTTP/2 frames, the upgrade path is probably being mishandled rather than successfully negotiated.
Why misapplied upgrades create a security blind spot
h2c is especially fragile because the upgrade boundary changes how the proxy interprets the connection. A system that switches protocols too early, too late, or only on some paths can create a split between content-aware HTTP handling and opaque tunneling. That split is where policy drift appears: routing, header-based controls, and authorization decisions may no longer be evaluated consistently.
This is most dangerous when the proxy assumes the upgrade has completed, but the backend never transitions into the expected HTTP/2 state. At that point, the front end may stop enforcing logic it normally applies to individual requests, while the backend still receives traffic in an unexpected format. The result is not just failure, but an altered trust boundary.
Misapplication can also show up as different behavior between direct and proxied access. If a request path is blocked when sent normally but succeeds once the connection has been upgraded or tunneled, the upgrade path is changing the security model in a way operators did not intend.
What to check first in a suspicious h2c path
Start with whether the proxy is doing protocol negotiation as designed, not just forwarding upgrade headers. Confirm that the same route, backend, and request pattern produce the same result under direct HTTP/1.1, h2c upgrade, and any intermediate proxy hop. Inconsistent behavior is usually more revealing than a single failed request.
Then verify what the backend actually receives after the 101 response. A healthy h2c path should show a genuine HTTP/2 transition, not merely a header exchange followed by tunnel-like forwarding. If the connection stops looking like HTTP, your controls need to be validated at the point where semantics change, not only at the edge.
Finally, review whether any security policy depends on parsing headers, paths, or methods after the upgrade. If those controls only exist in the HTTP-aware portion of the stack, the upgrade boundary can become an evasion point. NIST Cybersecurity Framework 2.0 is useful here as a way to frame the issue as a control-consistency problem across identify, protect, detect, respond, and recover functions.
Risk and Threat Considerations
Misapplied h2c upgrades can create a control bypass if a proxy stops enforcing content-aware policy once the connection is upgraded or tunneled. That matters because the visible symptom may look like a successful protocol transition even when the real problem is loss of inspection, inconsistent routing, or weakened authorization.
Failure mechanism: The proxy or back end treats the upgraded channel differently from ordinary HTTP traffic, so security checks that depend on request parsing, header handling, or path-level policy no longer run consistently.
Impact: Attackers or buggy clients can exploit the gap to reach paths that should have been blocked, hide malicious requests inside a tunnel, or create hard-to-triage differences between direct and proxied access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 — Identity Management, Authentication, and Access Control | Upgrade handling can affect access control enforcement across the proxy boundary. |
| PR.DS-01 — Data-at-Rest and Data-in-Transit Protected | h2c misapplication changes how traffic moves and whether it remains inspectable in transit. | |
| DE.CM-01 — Networks and Network Services Monitored to Detect Potential Incidents | Inconsistent upgrade behavior is detectable through path-specific monitoring and testing. | |
| Recommendation — Verify that upgraded connections still enforce the same access decisions as normal HTTP flows. Validate that traffic remains protected and governed after protocol switching. Monitor upgraded paths for inconsistent behavior, stalls, and unexpected tunneling. | ||
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Misapplied upgrades can bypass content-aware flow controls at the proxy boundary. |
| SC-7 — Boundary Protection | The issue is a boundary control problem where the proxy may stop mediating traffic as expected. | |
| SI-4 — System Monitoring | Observable symptoms include 101 responses, path inconsistency, and loss of HTTP-aware behavior. | |
| Recommendation — Enforce information flow rules consistently before and after any protocol upgrade. Confirm boundary controls still mediate requests after h2c negotiation. Alert on upgrades that succeed without the expected HTTP/2 behavior or policy enforcement. | ||
Practitioner Guidance
What to verify: Test the same endpoint through every hop that can terminate or forward the connection, and confirm that the upgraded flow still enforces the same access and routing decisions as the non-upgraded flow. If the behavior changes after 101, treat that as a control-design issue, not just a transport quirk.
Common mistake: Teams often validate only that the upgrade header exchange succeeds, then assume the rest of the stack will keep applying the same policy. The more important question is whether the proxy still understands and governs the traffic after the protocol switch.
Decision rule: If access control or inspection disappears once the connection becomes a tunnel, disable or constrain h2c on that path until you can prove that enforcement survives the upgrade boundary.
Practitioner takeaway: A successful h2c upgrade is only safe when the security controls that mattered before the switch still operate after it.
Related resources from NHI Mgmt Group
- How should security teams prevent authorization flaws when front end services proxy requests to back end data systems?
- Why do parser differences between proxies and back-end services matter?
- What breaks when patient identity verification is treated as a back-end matching problem?
- How should organisations plan gateway upgrades when a supported version is entering end of life?
