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 invalidContent-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]