HTTP Request Smuggling Explained for Website Owners

Short answer: HTTP request smuggling is an attack that exploits a disagreement between two servers about where one request ends and the next begins. A front-end server such as a proxy, load balancer or CDN passes traffic to a back-end server. If they read the length of a request differently, an attacker can hide extra bytes that the back end treats as the start of the next visitor’s request. The risk is reduced with up-to-date software, consistent settings, HTTP/2 end to end and rejecting ambiguous requests.

The setup: servers in a chain

Many websites do not answer visitors directly. A request first reaches a front-end server, which might be a CDN, a load balancer, a reverse proxy or a web application firewall. That server forwards the request to a back-end server, which runs the application. To save time, the two usually keep a connection open and send many requests from many different visitors through it, one after another. We described why in our guide to content delivery networks.

This arrangement works only if both servers agree exactly where each request ends. HTTP gives two ways to say how long a request body is: a Content-Length header, which states the number of bytes, and a Transfer-Encoding header with the value chunked, which sends the body in pieces, each with its own size, and ends with a zero-size piece. The standard says that when both headers are present, the chunked method wins. But not every server follows that rule in every situation.

How a disagreement becomes an attack

An attacker sends a request that is deliberately ambiguous. It contains both headers, or a header written in an unusual way, so that one server obeys one header and the other server obeys the other. Researchers describe the combinations with short names:

CL.TE: the front end uses Content-Length, and the back end uses Transfer-Encoding.
TE.CL: the front end uses Transfer-Encoding, and the back end uses Content-Length.
TE.TE: both support chunked encoding, but one can be tricked into ignoring it by a slightly malformed header.
HTTP/2 downgrade variants: the front end speaks HTTP/2 with the visitor but converts the request into HTTP/1.1 for the back end, and the conversion preserves or creates an ambiguous length.

The result is that the front end believes it forwarded one complete request, while the back end believes that some of the bytes belong to the beginning of another. Those extra bytes wait on the shared connection. When the next request arrives, from a completely different visitor, the back end glues the leftover bytes in front of it. The innocent visitor’s request has now been changed by the attacker.

What an attacker can do with it

Because the attacker can influence the start of someone else’s request, the impact can be large. Typical outcomes include:

Bypassing front-end protections. Rules in a firewall or a proxy that block access to admin paths can be skipped, because the hidden request never passed through the check as a separate request.
Capturing other users’ requests. The attacker can arrange that part of the next visitor’s request, including cookies or tokens, is stored somewhere the attacker can read. See our article on session hijacking for what stolen session data allows.
Serving harmful responses to users. The visitor may receive a response meant for a different request, such as a redirect to another site or a page containing injected script.
Poisoning caches. If a cache stores the wrong response under a popular address, many visitors receive it. This links request smuggling with web cache poisoning.
Hiding malicious traffic. Logs on the front end show a normal request, and the harmful one is only visible on the back end.

The flaw is not in the application code. A perfectly written website can be exposed because of the way the servers in front of it are combined and configured.

Who is at risk

A simple website on one ordinary server with no proxy in front has little exposure. The risk rises as the chain gets longer. Sites at higher risk include:

sites behind a CDN, a load balancer or a reverse proxy, especially if the vendors of the proxy and the origin server differ,
applications behind several layers, such as a CDN, a web application firewall and a container gateway,
servers running old versions of proxies and web servers,
setups that convert HTTP/2 to HTTP/1.1 before the origin.

Large providers have fixed many known variants and test continuously, so a well-maintained managed platform is usually safer than a self-assembled stack with old parts. New variants are still discovered from time to time, which is why updating matters.

A simple way to picture it

Imagine a post room where a clerk at the front desk takes letters from visitors and hands them, one by one, to a clerk in the back office through a single slot. Each letter has a note on the outside saying how many pages it contains. Now an attacker hands over a letter with two conflicting notes. The front clerk counts pages one way and passes the whole thing through as a single letter. The back clerk counts the other way, stops early and treats the remaining pages as the first pages of the next letter. When the next real letter arrives, the leftover pages are stuck to the front of it, and the back office acts on a message that nobody intended.

The analogy shows why the problem is so hard to see. Each clerk follows a rule, and each looks correct on its own. Only the combination fails, and only when the slot is shared between different senders.

How to reduce the risk

Keep every layer updated. Update the CDN configuration, proxy, load balancer, web server and application framework. Many request smuggling issues are fixed in routine security releases. See our guide to tracking security advisories.
Prefer HTTP/2 end to end. HTTP/2 has a clear, binary way to state the length of a message, which removes the ambiguity. Problems come mostly from the conversion back to HTTP/1.1. Our article on HTTP/2 and HTTP/3 explains the protocols.
Configure the front end to reject ambiguity. It should refuse requests that contain both Content-Length and Transfer-Encoding, duplicate length headers, malformed header names or unusual whitespace, instead of trying to repair them.
Use the same type of server in the chain where you can, or at least test that both layers handle edge cases the same way.
Do not reuse back-end connections across users when the risk justifies the cost. Opening a new back-end connection for each request removes the shared stream, but it costs performance, so it is a trade-off for sensitive applications.
Use a web application firewall as an extra layer, not the only one. Our article on the web application firewall explains its limits.
Monitor unusual responses. Unexplained errors, requests that suddenly return the wrong page, or strange entries in the origin’s logs deserve a look. Our guide to reading access logs helps.

What website owners should do in practice

You do not need to become a network engineer. Ask three questions of your host or developer. Which proxies, CDNs and gateways sit in front of the application? Are they supported and updated? Has anyone tested the setup for request smuggling, for example during a professional penetration test? The answers decide whether the risk is theoretical or real.

If you use a managed hosting platform, check that it describes its security update policy. If you run your own stack, put the components on an update schedule and subscribe to their security announcements. For a broader picture, see the difference between a security scan and a penetration test, since automated scans rarely detect smuggling reliably.

What Site AI Audit can and cannot tell you

Site AI Audit checks the security basics of your site from the outside: the SSL certificate and its expiry, the HTTP to HTTPS redirect, security headers and exposed software versions. It does not send malformed requests or test how your proxy and server agree on message length, so it cannot detect request smuggling. The exposed-versions check is still useful, because old software versions are where known smuggling flaws live. You can run a free check of your website or see the plans.

The bottom line

Request smuggling is a flaw in how servers in a chain interpret the same bytes. It lets an attacker affect other visitors and bypass protections without touching your application code. Keep every layer updated, prefer HTTP/2 end to end, make the front end reject ambiguous requests and ask for a professional test when your site handles sensitive data.

FAQ

Is my small website at risk?

The risk is low for a single simple server with no proxy. It grows with every layer in front of the application, such as a CDN, load balancer or gateway.

Does HTTPS prevent request smuggling?

No. Encryption protects traffic between the visitor and the server, but the flaw lies in how servers interpret message length inside that traffic.

Can a firewall block it?

Some firewalls detect common patterns, but new variants appear. Updates and strict request handling are more reliable than filtering alone.

How would I know if I was attacked?

Signs include requests answered with the wrong page, odd errors and unusual entries only in origin logs. A professional test is the best way to find out.

Is HTTP/2 enough to remove the risk?

Not if the front end converts requests to HTTP/1.1 for the origin. Using HTTP/2 all the way to the origin and keeping software updated gives the best protection.