HTTP Request Smuggling: A Complete Guide to Types, Risks, and Prevention

Quick Overview: HTTP request smuggling exploits differences in how API gateways and backend systems parse HTTP requests. This guide covers its impact, attack types, causes, risks, and prevention techniques to help secure API gateway request handling.

Every request to your APIs crosses one chokepoint: the API gateway. It terminates TLS, enforces authentication, applies rate limits, and forwards traffic to your services over reused backend connections. That position is exactly what makes it a prize. If an attacker can make the gateway and the upstream service parse the same bytes differently, they can smuggle a hidden request through the one component that is supposed to inspect everything.

HTTP request smuggling attacks turn that parsing disagreement into a weapon. A single crafted request can bypass authentication policies the gateway enforces, poison the connection shared by other API consumers, or reach internal endpoints you assumed were unreachable. Because the gateway multiplexes many clients over pooled connections, one smuggled fragment can affect requests that were never yours.

In this guide, we’ll explain what HTTP request smuggling is, how it works in API gateways, the main attack types, what causes request parsing inconsistencies, the security risks involved, and how an API pentesting tool can help detect and prevent these vulnerabilities.

Your gateway can look secure while the real weakness sits behind it. Find what your routine scans don't see. Find What You're Missing

What is HTTP Request Smuggling in API Gateways?

HTTP request smuggling in an API gateway is an attack that exploits inconsistent HTTP request parsing between the gateway and its upstream services, allowing an attacker to inject a hidden request that one system treats as part of the first request while the other treats it as a separate, standalone request.

In a gateway topology, the gateway acts as the front-end parser, and the upstream service acts as the back-end parser. Both must agree on the boundary between one request and the next. When they do not, an attacker can send an ambiguous request whose end the gateway calculates one way, and the upstream calculates another. The leftover bytes the upstream did not consume become the start of the next request in the stream. The vulnerability class is catalogued as CWE-444 (Inconsistent Interpretation of HTTP Requests), and it was documented as early as 2005 before being widely repopularized through modern desync research.

The reason this is dangerous specifically at a gateway comes down to connection reuse. To stay fast, gateways keep persistent connections open to the backend and send many requests down the same connection, one after another. If a smuggled fragment is left unconsumed, it does not disappear. It waits at the front of that shared connection and gets prepended to whatever request arrives next, which may belong to a completely different API client. The parsing disagreement is the flaw; the pooled connection is what turns it into a cross-user attack.

Why is Preventing an HTTP Request Smuggling Attack Important?

A successful HTTP request smuggling attack can allow an attacker to manipulate how different servers interpret HTTP requests. This can help bypass security controls and gain access to resources or functionality that should be protected.

Depending on the application and attack path, HTTP request smuggling can allow attackers to:

• Access restricted resources, including admin interfaces
• Access sensitive application data
• Hijack user sessions
• Launch cross-site scripting (XSS) attacks
• Capture or abuse user credentials
• Bypass security controls between front-end and back-end servers

These are risks that can be created by smuggling attack can impact compliance, business, and the trust of your customers. So, it becomes critical to detect and prevent them on a priority basis.

Types of HTTP Request Smuggling

The main types of HTTP request smuggling are classified by which length header each parser trusts: CL.TE, TE.CL, and TE.TE for HTTP/1.1, plus HTTP/2 downgrade variants (H2.CL and H2.TE) and modern desync techniques such as CL.0 and request tunnelling.

HTTP/1.1 offers two ways to declare where a request body ends: the Content-Length header, which states the body size in bytes, and the Transfer-Encoding: chunked header, which ends the body with a zero-length chunk. Smuggling arises when the gateway and upstream resolve a request that carries both headers, or an obfuscated one, in different ways.

CL.TE

The gateway trusts Content-Length while the upstream trusts Transfer-Encoding. The gateway reads the full body as one request; the upstream stops at the zero-length chunk and treats the remaining bytes as a new request.

POST /orders HTTP/1.1  Host: api.example.com  Content-Length: 32  Transfer-Encoding: chunked  0  GET /admin/keys HTTP/1.1  X: x

TE.CL

The reverse: the gateway trusts Transfer-Encoding and the upstream trusts Content-Length. The gateway processes the chunked body and forwards it; the upstream reads only the number of bytes in Content-Length and leaves the rest as the beginning of the next request.

POST /orders HTTP/1.1  Host: api.example.com  Content-Length: 4  Transfer-Encoding: chunked  2c  GET /internal/metrics HTTP/1.1  X: x  0

TE.TE (header obfuscation)

Both sides support Transfer-Encoding, but the attacker obfuscates the header so only one parser honors it. Small departures from the specification such as an extra space, a tab, a duplicate header, or an unusual value cause one side to ignore Transfer-Encoding and fall back to Content-Length, recreating a CL.TE or TE.CL condition.

Transfer-Encoding: chunked  Transfer-Encoding: x  # duplicated, one parser ignores it  Transfer-Encoding:\[tab\]chunked # whitespace obfuscation

HTTP/2 Downgrade Variants: H2.CL and H2.TE

HTTP/2 carries an explicit message length in its framing, so end-to-end HTTP/2 removes the classic ambiguity. The problem is that most gateways speak HTTP/2 to clients but downgrade to HTTP/1.1 for upstream services that do not support HTTP/2. During that rewrite, a gateway that copies an attacker-supplied Content-Length (H2.CL) or forwards a smuggled Transfer-Encoding header (H2.TE) reintroduces the same desync on the downgraded connection.

Modern Variants: CL.0 and Request Tunnelling

Newer techniques do not require conflicting length headers at all. In CL.0 smuggling, the upstream ignores the Content-Length on certain endpoints and treats the body as a new request. Request tunnelling smuggles a request that the upstream answers on the same connection, letting an attacker read internal responses or leak headers the gateway added. These variants matter because they can survive some defenses that assume smuggling always depends on a header conflict.

The gaps attackers find aren't always the ones you expect. Put your APIs through deeper attack testing. Test Your APIs

What Causes HTTP Request Smuggling?

HTTP request smuggling is caused by inconsistent HTTP request parsing between the gateway and upstream services, most often from conflicting Content-Length and Transfer-Encoding handling, non-standard header parsing, unsafe HTTP/2 downgrading, and gateway misconfiguration combined with reused backend connections.

Dual Length Mechanisms in HTTP/1.1

The root cause is that HTTP/1.1 allows two ways to state body length. A request can carry both Content-Length and Transfer-Encoding. The specification says to prefer Transfer-Encoding, but that only removes ambiguity within a single server, not across a gateway and an upstream that implements the rule differently. These are the API gateway requests parsing vulnerabilities at the heart of the problem.

Inconsistent or Non-compliant Parsing

Real HTTP implementations tolerate different departures from the standard. One parser may accept an obfuscated Transfer-Encoding header while the other rejects it. When the gateway and upstream are different products, from different vendors, with different tolerance for malformed input, the odds of a parsing mismatch rise. Understanding how HTTP headers are interpreted and secured is central to closing these gaps.

Unsafe HTTP/2-to-HTTP/1.1 Downgrade

When the gateway downgrades HTTP/2 to HTTP/1.1 for the backend, it rewrites a message that had an unambiguous length into a format that does not. If the rewrite trusts attacker-controlled length headers instead of recalculating them, it manufactures a smuggling condition. This is why gateways fronting legacy HTTP/1.1 services are a common source of request smuggling vulnerabilities.

Gateway Misconfiguration and Connection Reuse

Configuration choices decide exploitability. Reusing upstream connections, permitting request bodies on methods that should not have them, and forwarding requests without normalizing ambiguous headers all widen the window. Connection reuse in particular converts a single desync into an attack that can hit other API consumers. Testing these paths is part of thorough API security testing.

What are Risks and Impact of HTTP Request Smuggling?

The security risks of HTTP request smuggling include bypassing gateway authentication and access controls, hijacking other users' requests and sessions, response queue poisoning, web cache poisoning, reaching internal endpoints, and delivering payloads such as reflected XSS to other API consumers.

Bypassing Gateway Authentication and Access Controls

The gateway is where authentication, authorization, and WAF rules live. A smuggled request reaches the upstream without passing through those checks, so restrictions the gateway enforces are simply skipped. This is the same failure mode as broken access control: a request reaches a resource it should never have been allowed to touch, except here the control is defeated at the infrastructure layer rather than in application code.

Request and Session Hijacking Across API Consumers

Because the smuggled fragment sits in a pooled connection, it can attach to the next legitimate request. An attacker can capture another user's request, including credentials, cookies, and tokens, or force the backend to serve one user with the response intended for another. On a busy gateway, repeated smuggling can poison connections at scale.

Response Queue Poisoning and Cache Poisoning

By desynchronizing the response queue, an attacker can shift which response is returned to which request, causing users to receive responses meant for others. If a cache sits behind the gateway, a smuggled request can poison cached entries so that malicious or incorrect content is served to many clients from a single injection.

You know what you've found. But what about what's still hiding? See what continuous security testing can uncover. See Your Testing Options

Internal Endpoint Exposure and Payload Delivery

Smuggling can route requests to internal or administrative endpoints that were assumed to be shielded by the gateway. It can also weaponize otherwise low-severity issues: a reflected cross-site scripting payload placed in a smuggled request can be delivered to another user's response even when it could not be triggered with a normal link. placed in a smuggled request can be delivered to another user's response even when it could not be triggered with a normal link.

How to Prevent HTTP Request Smuggling in API Gateways

To prevent HTTP request smuggling in API gateways, use HTTP/2 end to end and disable downgrading where possible, normalize or reject ambiguous requests at the gateway, validate rewritten requests during any downgrade, reject malformed and duplicate length headers, and test the gateway-to-upstream path continuously.

• Prefer HTTP/2 end to end: When the gateway and upstream both speak HTTP/2, the unambiguous framing removes the classic conflict. Disable HTTP downgrade unless a backend genuinely requires HTTP/1.1.
• Normalize, then reject: Have the gateway rewrite ambiguous requests into a single canonical form and reject anything still ambiguous, closing the connection rather than forwarding it.
• Validate on downgrade: If you must downgrade HTTP/2 to HTTP/1.1, recalculate length instead of trusting client-supplied headers, and reject rewritten requests that violate the HTTP/1.1 grammar.
• Refuse malformed input: Reject requests carrying both length headers, duplicated or obfuscated Transfer-Encoding, and bodies on methods that should not have them.
• Reconsider connection reuse: Disabling backend connection reuse limits some attacks, though it is a partial measure and does not stop request tunnelling.

These controls only hold if you verify them against your real gateway-and-upstream pair, since smuggling is a product of how two specific parsers interact. Runtime testing with dynamic application security testing exercises request boundaries the way an attacker would, and continuous automated penetration testing re-checks the path after every gateway or backend change so a configuration drift does not silently reopen the flaw.

Go beyond configuration checks and validate whether HTTP request smuggling flaws create real attack paths. Start for Free

Conclusion

HTTP request smuggling is a reminder that the API gateway is both your strongest control point and your single largest point of trust. When the gateway and your upstream services parse a request differently, that trust is exactly what an attacker turns against you, bypassing the controls you rely on and reaching users and endpoints that should have been out of reach. The flaw is subtle, it hides between components, and it does not show up in code review.

Since this weakness exists between components and only surfaces at runtime, it will not show up in a code review or a static scan. A modern API security scanner can help test the gateway and backend together, send carefully crafted requests that probe their request boundaries, and watch for differences in how each component interprets them. Re-test whenever you change the gateway, backend services, or HTTP protocol configuration. Treat request parsing as a security boundary of its own, and you can close the gap that requests smuggling exploits.