Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
HTTP request smuggling happens when two components in a request path—usually a front-end proxy and an origin server—parse different boundaries for the same request. Bytes one component considers part of a request body may be treated by the next as a separate request, potentially letting it bypass a control or interfere with traffic on a reused connection.
What is HTTP request smuggling?
A web request may pass through a chain of components, such as a CDN, a load balancer, a web application firewall (WAF), a reverse proxy, and an origin server. Each component has to determine where one request ends and the next begins. Smuggling is possible when parsers in that chain disagree.
The IETF’s RFC 9112, Section 11.2 (June 2022), defines request smuggling as a technique that exploits “differences in protocol parsing among various recipients” to hide additional requests inside an apparently harmless one. In practical terms, a front end might treat bytes as body content while a back end treats some of those same bytes as the start of another request.
Free tools Windows power users keep installed
One-click scans. No signup required.
The important property is different parsing or transformation along the request path—not necessarily two physical machines. If a connection is reused, bytes left over after one component’s interpretation can affect how a later request is read, desynchronizing the connection.
#1 Best Overall
How can two servers disagree about one request?
HTTP/1.1 needs a way to mark the end of a message body. Two relevant mechanisms are Content-Length, which gives the body’s length, and Transfer-Encoding: chunked, which marks the body’s end with a terminating chunk. A disagreement can occur if one component follows one framing rule while another follows the other—or if they interpret a transfer-encoding header differently.
Picture the front end deciding that a request ends at byte position A, while the back end decides it ends at position B. The intervening bytes may be forwarded, buffered, or parsed differently by each component. If the back end sees a request start in bytes the front end regarded as body data, it may process a request that the front end’s policy checks never evaluated as a separate request.
CL.TE, TE.CL, and TE.TE
| Pattern | Front-end interpretation | Back-end interpretation | How the discrepancy can matter |
|---|---|---|---|
| CL.TE | Uses Content-Length. |
Uses chunked Transfer-Encoding. |
The front end may forward bytes beyond the back end’s chunked end marker; the back end can read remaining bytes as another request. |
| TE.CL | Uses chunked Transfer-Encoding. |
Uses Content-Length. |
Bytes after the back end’s declared body boundary can be interpreted as a subsequent request. |
| TE.TE | Recognizes transfer encoding, or an obfuscated form of its header. | Interprets the same header differently, potentially ignoring it. | A parser difference induced by noncanonical or malformed syntax can make the components disagree about framing. |
These labels describe which framing behavior each parser follows; they are not separate protocols. TE.TE behavior depends on the exact syntax and implementations, so no single malformed header is a universal example. Whether any pattern is exploitable also depends on the particular proxy and origin, connection reuse, routing, and application behavior.
What can request smuggling let an attacker do?
If a later component sees a different request boundary, it may process a request that the front end did not inspect as a separate request. Depending on the site’s architecture and behavior, possible consequences include:
- Bypassing front-end access controls or other request checks.
- Reaching internal systems or sensitive resources through a request path the front end handles differently.
- Poisoning a web cache, so other visitors receive a response associated with the wrong request.
- Affecting another user’s request when desynchronized traffic is handled on a shared connection.
These are potential outcomes, not guaranteed results of every parsing discrepancy. Routing, cache behavior, connection pooling, and the application’s endpoints all influence impact.
Does HTTP/2 prevent request smuggling?
HTTP/2 carries message bodies in DATA frames with explicit frame lengths, avoiding the classic HTTP/1.1 choice between Content-Length and chunked transfer encoding when the relevant request path uses HTTP/2 consistently. That removes this particular framing ambiguity; it does not make every HTTP/2 implementation or deployment automatically safe.
Rank #4
A common complication is protocol downgrade: an edge service accepts HTTP/2 from the client but translates the request to HTTP/1.1 for an older origin. The origin then relies on HTTP/1.1 framing. If the front end translates or validates the request incorrectly, the conversion can create H2.CL or H2.TE conditions—HTTP/2-to-HTTP/1.1 cases involving conflicting or improperly handled framing.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPortSwigger researcher James Kettle wrote in “HTTP/2: The Sequel is Always Worse,” published August 5, 2021 and updated September 3, 2025: “HTTP/2 is easily mistaken for a transport-layer protocol that can be swapped in with zero security implications for the website behind it.” The practical distinction is whether HTTP/2 remains in use through the relevant chain or a downgrade introduces a new framing boundary that must be handled safely.
Best Value
- Used Book in Good Condition
| Deployment | Where the framing question arises | What to check |
|---|---|---|
| HTTP/2 end to end | The request stays on HTTP/2 through the relevant path. | Confirm that intermediaries and the origin actually use HTTP/2 for that path, and still validate parser behavior. |
| HTTP/2 at the edge, HTTP/1.1 to the origin | The edge translates the request into HTTP/1.1. | Check how the edge constructs and validates HTTP/1.1 framing, and test the translation path as well as client-facing HTTP/2. |
How do you prevent HTTP request smuggling?
The goal is consistent parsing across every component in the path. A defense at only one layer may not be enough if another layer still interprets the same bytes differently.
- Use HTTP/2 end to end where feasible. Avoid unnecessary downgrades, and verify the protocol used between each intermediary and the origin rather than relying only on the client-facing protocol.
- Validate any HTTP/1.1 request created during downgrade. Ensure the rewritten request has unambiguous, specification-compliant framing. Reject malformed header names, embedded newlines, invalid methods, or ambiguous framing instead of allowing different components to repair or interpret them inconsistently.
- Normalize or reject ambiguous input at the front end. Configure the back end to reject any ambiguity that remains; do not assume the edge’s interpretation will be shared by the origin.
- Close connections after parsing or framing errors. RFC 9112 says a server receiving a sequence that does not match the HTTP-message grammar, apart from specified robustness exceptions, “SHOULD respond with a 400 (Bad Request) response and close the connection.” Closing the connection prevents leftover bytes from contaminating a reused one.
- Audit the full request path. Include every proxy, load balancer, WAF, CDN, and origin. The components must agree across the chain, not just with the first server the client reaches.
RFC 9112 also warns that forwarding a message containing both Transfer-Encoding and Content-Length can create smuggling risk if downstream recipients parse it incorrectly. An intermediary that forwards such a message must remove Content-Length and correctly process Transfer-Encoding. In practice, follow the standard and ensure that the components in your own chain handle such input consistently.
Disabling connection reuse can limit some effects in some deployments, but it is not a complete fix: it does not correct inconsistent parsing on every request path.
How should you test for request smuggling?
Test both HTTP/1.1 handling and any HTTP/2-to-HTTP/1.1 translation path in an authorized staging environment or assessment. Confirm a suspected issue against the actual proxy-and-origin chain: the same configuration, protocol path, routing, and connection behavior matter. A front end that advertises HTTP/2 does not establish that its origin connection also uses HTTP/2.
PortSwigger’s HTTP Request Smuggler extension is documented as automating detection and testing; its listing describes compatibility with Burp Suite DAST, Professional, and Community editions. Burp documentation also covers protocol selection and HTTP/2 handling, including HTTP/1 testing for classic CL.TE and TE.CL cases. Treat an extension as an assessment aid, not a guarantee: automated findings need confirmation against the deployed path, and a negative result does not prove that every route or parser combination is safe.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
