HTTP request smuggling (desync)

When it applies

Requests pass through a front-end (proxy/CDN/LB) to a back-end, and the two disagree on where one request ends and the next begins (Content-Length vs Transfer-Encoding parsing).

Why it works

If the front-end and back-end compute request boundaries differently, part of your request is interpreted by the back-end as the start of the next request — which belongs to another user. That lets you prepend data to victims' requests: bypass controls, capture their requests, or poison caches.

Method

1. Detect safely with timing: use Burp's HTTP Request Smuggler / the desync toolkit — send a CL.TE / TE.CL probe crafted to make the back-end wait, and watch for the tell-tale delay.
2. Confirm by smuggling a prefix that changes a following request's response (e.g. a controlled 404→ redirect on the victim's path) without harming users.
3. Exploit (in scope, carefully): bypass front-end auth/routing, capture other users' requests (steal cookies/tokens), or web-cache poisoning via the smuggled prefix.
4. CL.0 / H2 desync: also test HTTP/2 downgrade and CL.0 variants on modern stacks.