h2c upgrade traffic can create risk because the proxy may stop inspecting content after a 101 Switching Protocols response and simply relay TCP bytes. If the back end accepts the upgrade, the client can keep using the tunnel and send additional HTTP/2 requests that bypass path-based restrictions on the edge. The core failure is trusting proxy filtering alone.
Why proxy inspection breaks down after an h2c upgrade
The access-control problem begins when the proxy treats the upgrade as a transport transition instead of an application request boundary. Once the backend agrees to switch protocols, the intermediary may no longer parse the stream as ordinary HTTP in a way that supports path, method, or header enforcement. The result is that the proxy can become a blind relay for a conversation it no longer understands.
That matters in proxied applications because the edge control often assumes it is still mediating each request. With h2c, the client and backend can continue speaking HTTP/2 over a tunnel that bypasses the proxy’s normal per-request decision point, so the security model quietly changes after the initial handshake.
How the bypass happens in practice
In a typical pattern, the client sends an HTTP/1.1 request with an upgrade header, the proxy forwards it, and the backend responds with 101 Switching Protocols. After that response, the proxy may stop applying request-level policy and simply pass TCP bytes. If the backend then accepts and processes the upgraded stream, the client can keep issuing additional HTTP/2 requests on the same connection.
The key security shift is that those later requests may never be re-evaluated by the proxy’s path routing or allowlist rules. A rule that was meant to protect one URI, verb, or handler can be bypassed if the tunnel gives the client a separate channel to the same origin. Authorisation Models Guide is useful here because the issue is not transport alone, it is whether the enforcement point still makes a fresh access decision for the protected action.
That is why the edge must not assume that “connection established” means “access already checked.” If the application relies on the proxy for enforcement, the proxy has to remain an active policy boundary for the full lifetime of the request flow, not just for the first hop.
What controls actually reduce the risk
The safest pattern is to prevent ambiguous trust boundaries in the first place. Disable h2c where it is not required, or terminate and re-originate traffic in a way that preserves inspection and authorization at the correct layer. If upgrade traffic must be supported, the backend and proxy need explicit agreement about which requests may upgrade, which identities may do so, and which routes remain protected after the protocol switch. The central question is whether the proxy is enforcing access or merely forwarding bytes after the initial handshake.
Practitioners should treat this as an access-control design issue, not a cosmetic protocol choice. IAM and IGA Basics is a helpful reference because the failure mode is the same class of mistake seen in broader authorization systems: policy is assumed to exist at the front door, but privileged paths remain reachable once the request shape changes. For service-to-service environments, Privileged Access Management Guide reinforces the need to bound privileged paths and reduce standing trust in long-lived channels.
Risk and Threat Considerations
h2c upgrade traffic is risky because it can convert a controlled HTTP request path into an opaque tunnel that keeps carrying higher-value traffic. Once that happens, an attacker who can reach the upgrade path may be able to smuggle additional requests through a connection that was only checked at the start, creating a bypass around edge controls and route-based segregation.
Failure mechanism: The proxy stops applying request semantics after the upgrade and relays the stream without re-enforcing path, method, or header restrictions, while the backend continues to accept new HTTP/2 requests over the same channel.
Impact: Protected endpoints can become reachable through a tunnel that bypasses edge policy, which can lead to unauthorized access, broken tenant isolation, and weaker auditability of who reached which backend action.
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, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | h2c upgrades can bypass request-level enforcement at the proxy boundary. |
| SC-7 — Boundary Protection | The issue is failure of the proxy boundary to keep enforcing policy after protocol switching. | |
| Recommendation — Enforce access decisions on every protected request path, including post-upgrade streams. Preserve inspection and filtering at trusted boundaries or block the upgrade path. | ||
| OWASP ASVS | V8 — Authorization | The bypass weakens request authorization checks on protected endpoints. |
| Recommendation — Revalidate authorization for every protected action rather than trusting the initial handshake. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Upgraded traffic can reach functions the proxy intended to restrict. |
| Recommendation — Protect function-level routes so transport upgrades cannot bypass authorization. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The risk is excessive reachability when the edge no longer enforces route access. |
| Recommendation — Restrict access paths so protocol changes cannot widen effective permissions. | ||
Practitioner Guidance
What to verify: Confirm whether the proxy continues to inspect and authorize traffic after 101 Switching Protocols, or whether it becomes a transparent relay. Test the exact routes you intend to protect, because a configuration that looks correct on the first request may fail on the second request inside the upgraded stream.
Decision rule: If the security requirement depends on the proxy seeing every request, do not permit h2c upgrade on that path. If upgrade is unavoidable, require a design that preserves enforcement at the application or service boundary, not only at the edge.
Practitioner takeaway: Treat protocol upgrade as a boundary change, not a transport detail, because any control that only works before the tunnel exists is not a reliable access control.
