Parser disagreement
HTTP request smuggling occurs when two components on one connection disagree about where a request ends and the next begins. An attacker crafts an ambiguous message so a front end assigns bytes to one request while a back end treats some bytes as a second request. The connection becomes desynchronized.
The smuggled request can inherit another user's connection, bypass a front-end control, poison a cache, reach an internal route, or capture a later response.
Message framing
HTTP/1.1 uses defined message-length rules. Conflicting Content-Length, invalid transfer coding, duplicate fields, obsolete syntax, and parser-specific tolerance create risk. A component must reject ambiguous or invalid framing instead of choosing a convenient interpretation and forwarding the result.
When translating HTTP/2 or HTTP/3 to HTTP/1.1, the intermediary must construct one unambiguous downstream message. It must not forward prohibited connection-specific fields or attacker-controlled framing. Every hop must agree on normalization, header limits, and invalid-message handling.
Connection and routing controls
Keep proxy, gateway, cache, service mesh, and origin software current. Use protocol combinations the vendors test together. Disable unnecessary downgrade paths. Reject messages with conflicting length information, invalid transfer coding, whitespace ambiguity, malformed field names, or data after the declared body.
Test the deployed chain, not each component alone. Include keep-alive reuse, front-end to back-end translation, cache behavior, alternate routes, and error paths. Monitor unusual protocol errors and connection desynchronization signals without assuming logs will show the hidden request clearly.
Failure and residual risk
Normalizing one field can create a different valid message for the next hop. Closing a client connection does not help if the ambiguous bytes already entered a reused upstream connection. A web application firewall can parse the request differently from the proxy it is meant to protect. HTTP/2 at the edge does not remove risk when the internal hop downgrades to HTTP/1.1.
Pomerium boundary
Pomerium is one HTTP intermediary in a possible chain. Operators must keep it and adjacent proxies current, avoid ambiguous double-proxy behavior, and test the exact deployed protocol path. The upstream server and other intermediaries must also reject invalid framing. Route policy cannot authorize a request that one component does not parse as the same message.
Evaluation checklist
- Which protocols and versions run on every hop from client through origin?
- Does any hop translate HTTP/2 or HTTP/3 to HTTP/1.1?
- Do all components reject conflicting length fields and invalid transfer coding?
- Can an error path, cache, or connection pool reuse a desynchronized connection?
- Are normalization and field limits compatible across every intermediary?
- Have tests exercised the complete deployed chain with safe request-desynchronization probes?
