HTTP request smuggling becomes possible when two components disagree about where one request ends and the next begins. Treat the reverse proxy, load balancer, gateway, CDN and application server as one parsing chain, especially where HTTP/2 is converted to HTTP/1.1.
Last updated: November 15, 2026.
Client (HTTP/2)
-> CDN or edge proxy
-> load balancer (possible HTTP/1.1 downgrade)
-> application proxy
-> application server
For every hop, record:
- accepted protocol versions
- request-body framing rules
- header normalization behavior
- connection reuse after parse errorsDocument the real production route, including managed services. A secure setting on the application server does not compensate for an intermediary that forwards an ambiguous request differently.
Remove parser disagreements
The OWASP testing guide identifies conflicting body framing, protocol downgrades, header normalization, H2C upgrades, and backend connection reuse as important risk areas. RFC 9112 section 6.3 defines HTTP/1.1 message-body length and requires recipients to handle conflicting framing safely. Use supported versions of every component and configure the chain to reject malformed or ambiguous framing instead of choosing one interpretation and forwarding it.
Disable H2C upgrades when they are not required. Avoid unnecessary protocol conversion on untrusted traffic. Do not forward client-supplied hop-by-hop headers blindly, and terminate the backend connection after a parsing error so leftover bytes cannot affect the next request.
Test the deployed chain safely
Test through the same CDN, gateway and proxies used in production, not directly against only the application. Compare how each hop handles duplicate or conflicting framing headers and HTTP/2-to-HTTP/1.1 translation. Perform active desynchronization testing only in an authorized non-production environment because a malformed request can corrupt another request on a shared backend connection.
Monitor unexplained 400 responses, mismatched responses, abnormal connection reuse and cross-request anomalies. Correlate edge and origin request identifiers when investigating suspicious responses. A web application firewall can add detection, but it cannot guarantee safety when the proxy and origin parse requests differently. Re-run the assessment after proxy, load balancer, web server or protocol configuration changes.
