What happens when an h2c tunnel is created through a reverse proxy that enforces access only at the edge?

When the tunnel is created, the proxy can stop acting as a security checkpoint and become a blind transport pipe. That allows the client to multiplex additional HTTP/2 requests over the same connection and potentially reach restricted internal endpoints. If the back end trusts the tunneled traffic, edge-only access controls no longer protect private routes.

How the Tunnel Changes the Proxy’s Security Role

An h2c tunnel changes the proxy from an enforcement point into a transport path for a single upgraded HTTP/2 connection. If the proxy only checks access at the edge, it may never inspect the tunneled requests that follow, so the back end can receive traffic the edge would have blocked. The security boundary shifts from the proxy to whatever still validates each request downstream.

That matters because HTTP/2 multiplexing lets multiple streams ride the same established connection. Once the tunnel exists, the client can send additional requests through the pipe without re-entering the proxy’s normal authorization logic. In practice, this is less about “bypassing the proxy” in a general sense and more about the proxy losing visibility after the protocol upgrade.

When the back end trusts the connection as already approved, the tunnel can expose internal-only routes, admin endpoints, or metadata services that were never meant to be reachable from the edge. The exact outcome depends on how the reverse proxy, upstream server, and route-level controls are configured, but the core failure is the same: edge-only policy is no longer enough once the connection becomes a tunnel.

Why h2c Tunnels Are a Boundary-Bypass Problem

An h2c tunnel is dangerous when the proxy accepts an HTTP/1.1 Upgrade to cleartext HTTP/2 and then forwards the upgraded stream without reapplying request-level checks. The result is a trust gap between connection admission and resource authorization. If your design assumes the proxy is the place where every request is judged, the tunnel breaks that assumption.

This is especially important in environments that separate public and private routes behind the same reverse proxy. A client that can negotiate h2c may not need a new session or a new authentication step to reach more than the original front-door URL. That makes the issue materially different from a simple misrouted request, because the attacker or client can reuse one approved connection for additional traffic.

Well-designed upstream services should still enforce their own authorization and routing rules, and sensitive endpoints should not rely on the proxy alone for protection. Where internal APIs exist behind the same edge device, the safe assumption is that transport-level trust and authorization are not the same thing.

What Practitioners Should Check Before Allowing Upgrade Paths

Before enabling h2c or any upgrade-based forwarding, confirm whether the proxy revalidates each request after the upgrade or merely forwards the tunnel. A configuration that is safe for one endpoint can be unsafe when the same listener also fronts private services, because the tunnel may inherit the original edge decision while hiding later requests from policy enforcement.

Verify that sensitive back-end routes enforce authorization independently of the edge proxy.
Review whether h2c, Upgrade, CONNECT-like behaviors, or protocol translation are permitted on listeners that front internal services.
Test for multiplexed requests reaching paths that should only be available through separate authenticated entry points.

Risk and Threat Considerations

Once a reverse proxy turns into a blind pipe, the main risk is unintended reachability, especially to internal endpoints that were assumed to be shielded by edge-only controls. That can expose administrative functions, internal APIs, or backend-only metadata to any client that can establish the tunnel and continue sending HTTP/2 streams.

Failure mechanism: The proxy authenticates or authorizes the initial connection, then forwards the upgraded h2c session without enforcing request-level policy on subsequent multiplexed streams.

Impact: Private routes may become reachable from outside the intended trust boundary, creating exposure, privilege abuse, and possible lateral movement into internal services.

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 surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
OWASP API Security Top 10	API5 — Broken Function Level Authorization	h2c tunneling can expose backend functions beyond edge checks.
Recommendation — Enforce function-level authorization on every sensitive backend route.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Edge-only trust can overexpose internal routes and privileges.
	IA-9 — Service Authentication	Tunnelled service traffic needs authenticated upstream trust, not only edge checks.
Recommendation — Limit each request path and service to the minimum required access. Authenticate service-to-service hops before accepting tunneled requests.
ISO/IEC 27001:2022	A.5.15 — Access control	The scenario hinges on enforcing access decisions beyond the edge proxy.
Recommendation — Apply access control at both the proxy and the protected service.

Practitioner Guidance

What to verify: Treat protocol upgrade handling as a security control, not just a performance feature. Confirm that route authorization is enforced where the request is ultimately processed, and test the exact behavior of upgraded HTTP/2 traffic rather than assuming the proxy still inspects it.

Common mistake: Teams often harden the edge and stop there. If the back end trusts the upstream hop too much, edge-only restrictions are fragile; the safer pattern is defense in depth, with the proxy and the application both enforcing access decisions.

Practitioner takeaway: If h2c is permitted, the key question is not whether the first request was allowed, but whether every later request is still evaluated against the right trust boundary.