Browser HTTP Request Smuggling

Browser-powered desynchronization, also called client-side request smuggling, uses a victim’s browser to place a misframed request on a persistent connection. A subsequent request can then be interpreted out of sync by the server. Unlike classic front-end/back-end (FE/BE) request smuggling, the payload is constrained to syntax a browser can send.^[1]^[2]

Testing considerations

Use only headers and syntax that a browser can emit through navigation, Fetch, or form submission. Traditional header obfuscations such as unusual linear whitespace (LWS), duplicate Transfer-Encoding (TE) fields, or an invalid Content-Length (CL) generally cannot be emitted by browser JavaScript.^[1]^[2]
Look for endpoints and intermediaries that reflect input, cache responses, or reuse connections. Potential impact includes cache poisoning, disclosure of front-end-injected headers, and bypasses of front-end path or method controls.
Connection reuse is essential: the crafted request must share the same HTTP/1.1 or HTTP/2 connection with a later request for the desynchronization to affect it. Connection-locked or otherwise stateful server behavior can increase the impact.^[1]^[2]
Prefer primitives that do not require custom headers, such as path confusion, query-string injection, and body shaping through form-encoded POST requests.^[1]^[2]
Distinguish a real server-side desynchronization from HTTP pipelining artifacts. Repeat the test without connection reuse and, where applicable, use the HTTP/2 nested-response technique.^[3]