HTTP Request Smuggling in API Gateways

Your API gateway enforces authentication, rate limiting, and access control. But what if an attacker slips a second, hidden request past the gateway and delivers it directly to your backend?

HTTP request smuggling exploits disagreements between how an API gateway and backend server determine where one HTTP request ends and another begins. When both parse headers differently, an attacker can embed a smuggled request inside a legitimate one, bypassing every security control the gateway enforces.

The Salt Labs State of API Security Report found that 95% of organizations experienced security problems in production APIs. Request smuggling falls under API8:2023 (Security Misconfiguration) in the Open Web Application Security Project (OWASP) API Security Top 10.

For a full breakdown, see our guide to the 2023 OWASP API Top 10.

How Request Smuggling Attacks Work in API Gateways

HTTP/1.1 provides two ways to define request body length: the Content-Length header (byte count) and the Transfer-Encoding: chunked header (chunk-based). A request smuggling attack sends both headers in one request. The gateway uses one to determine the boundary, while the backend uses the other, causing leftover bytes to become a new smuggled request.

In API gateway architectures, the impact is amplified because gateways multiplex many client connections over shared backend connections. A single smuggled request can poison the connection and affect other users' API calls. 

Here are the three classic attack types:

• CL.TE. The gateway reads Content-Length and forwards the full body. The backend honors Transfer-Encoding: chunked, terminates early at the 0 marker, and treats remaining bytes as a new request.
• TE.CL. The gateway processes Transfer-Encoding and sends the chunked body. The backend reads only the bytes specified by Content-Length, leaving the smuggled request in the buffer.
• H2.CL (HTTP/2 downgrade). The gateway accepts HTTP/2, then downgrades to HTTP/1.1 for the backend. A Content-Length: 0 header causes the backend to ignore the body, which becomes a smuggled request.

Why API Gateways Are Prime Targets

API gateways present unique request smuggling risks. Understanding security misconfiguration in APIs helps explain why:

• Single enforcement point. Gateways enforce authentication, authorization, and rate limits. Smuggling bypasses all controls in one step, delivering unauthenticated requests to backend APIs.
• Connection reuse at scale. Gateways maintain persistent pools to backend microservices. A smuggled request on a shared connection can hijack another user's session or poison responses.
• HTTP/2 to HTTP/1 downgrade. Many gateways accept HTTP/2 from clients but forward HTTP/1.1 to backends, creating parsing mismatches that attackers exploit.
• Mixed parsers across microservices. Different backend services may use different HTTP libraries with inconsistent parsing behavior, widening the attack surface.

Pairing gateway hardening with REST API security best practices closes the most common gaps.

Common Request Smuggling Payloads

Security teams should test API gateways against these payloads:

CL.TE payload:

POST /api/v1/data HTTP/1.1

Host: api.example.com

Content-Length: 6

Transfer-Encoding: chunked

0

X

The gateway forwards 6 bytes. The backend terminates at 0 and treats X as the next request on the shared connection.

TE.CL payload:

POST /api/v1/data HTTP/1.1

Host: api.example.com

Content-Length: 3

Transfer-Encoding: chunked

8

SMUGGLED

0

The gateway sends the chunked body. The backend reads 3 bytes per Content-Length, leaving SMUGGLED in the buffer.

Obfuscated TE (TE.TE): Attackers use variations like Transfer-Encoding: xchunked, tab characters, or line folding to trick one server into ignoring the header.

Real-World API Gateway Smuggling Vulnerabilities

Request smuggling flaws have hit widely deployed API infrastructure. Here are documented vulnerabilities affecting gateways in production:

• CVE-2024-53008 (HAProxy). Crafted requests exploiting Content-Length and Transfer-Encoding inconsistencies bypassed Access Control Lists (ACLs) at the proxy layer, reaching restricted backend endpoints.
  
  
• CVE-2023-40225 (HAProxy). HAProxy forwarded empty Content-Length headers in violation of RFC 9110. Backend servers could interpret the payload as an additional request, enabling smuggling through widely deployed infrastructure.
  
  
• CVE-2024-33452 (Kong Gateway / OpenResty). Front-end proxies treated a HEAD request with a body as one request, but Kong split the same request into two pipelined requests. Attackers used the flaw to bypass WAF rules and desync response queues.

How to Detect Request Smuggling in APIs

Standard API scanners miss request smuggling because detection requires ambiguous requests and response analysis. Our API security checklist covers the full workflow, but here are key methods:

• Timing-based detection. Send requests with conflicting Content-Length and Transfer-Encoding headers. A backend waiting for data that never arrives produces a timeout, confirming a parsing disagreement.
• Differential response testing. Smuggle a request targeting a non-existent path. A 404 on the next legitimate request confirms the smuggled content was prepended.
• Automated API security testing. Purpose-built API security testing platforms generate CL.TE, TE.CL, TE.TE, and H2 downgrade payloads across every endpoint at scale.

5 Strategies to Prevent API Gateway Request Smuggling

Use our automated API security testing guide alongside these strategies:

1. Use HTTP/2 end-to-end

HTTP/2 uses frame-based length fields, eliminating the Content-Length vs. Transfer-Encoding ambiguity that makes smuggling possible. When every component in the request chain speaks HTTP/2, there is no plaintext header boundary to manipulate.

• Configure all backend services to accept HTTP/2 directly and disable HTTP/1.1 downgrading at the gateway layer.
• For backends that cannot support HTTP/2 natively, gRPC-based service meshes provide a viable alternative since gRPC runs over HTTP/2 by default, inheriting its length-framing protections.
• Audit gateway settings after every infrastructure update to confirm downgrade remains disabled.

2. Disable backend connection reuse

Persistent connection pools between the gateway and backend are the conduit for smuggled requests. When multiple clients share a single backend connection, a smuggled payload from one user pollutes the stream for the next.

• Disabling reuse forces each request onto a fresh connection, preventing cross-user contamination.
• The tradeoff is higher latency from repeated TCP handshakes, but the security gain outweighs the cost for APIs handling sensitive data.
• If fully disabling reuse is not feasible, configure the gateway to close backend connections after every response that returns an unexpected status code or content length mismatch.

3. Normalize and reject ambiguous requests

Configure the gateway to reject any request containing both Content-Length and Transfer-Encoding headers. Strip obfuscated header variations before forwarding to backend services. A strict normalization policy at the gateway edge should also block the following patterns:

• Content-Length values that do not match the actual body size
• Empty Content-Length headers (the vector behind CVE-2023-40225)
• Transfer-Encoding values other than chunked
• Headers containing tab characters, line folding, or trailing whitespace

In HAProxy, the option httpchk and http-request deny directives enforce these rules. In Nginx, header sanitization modules and proxy_pass_request_headers provide similar control.

4. Enforce consistent HTTP parsing

Run the same HTTP library or parsing rules on the gateway and every backend service. When both layers interpret request boundaries identically, attackers cannot exploit interpretation differences.

Where running identical software is not practical, document exactly how each component handles edge cases and test each one in isolation:

• Duplicate Content-Length or Transfer-Encoding headers
• Malformed chunk sizes or missing terminating 0 chunks
• HEAD requests containing a body (the vector behind CVE-2024-33452)
• Transfer-Encoding values with non-standard casing or extra spaces

Catching these mismatches proactively eliminates the parsing disagreements attackers rely on.

5. Integrate continuous API security testing in CI/CD

Gateway configurations change with every infrastructure deployment. A single Nginx or HAProxy config update can reintroduce smuggling flaws that were previously patched.

• Running automated API security testing in a Continuous Integration/Continuous Deployment (CI/CD) pipeline catches vulnerabilities before traffic reaches production.
• Automated platforms send CL.TE, TE.CL, TE.TE, and H2 downgrade payloads against every endpoint on each build.
• Header normalization rules are verified across gateway updates, backend library upgrades, and service mesh changes with zero manual scripting.

Close the Gaps Before Attackers Smuggle Through

A single request smuggling flaw bypasses every security control enforced by the API gateway. HTTP/2 end-to-end, strict header normalization, and continuous testing close those gaps.

APIsec tests every endpoint for OWASP API Top 10 vulnerabilities, including gateway misconfigurations that enable smuggling.  

Start a free scan and uncover what your tools miss.

FAQs

What is HTTP request smuggling in API gateways?

HTTP request smuggling occurs when an API gateway and backend interpret request boundaries differently, allowing attackers to inject hidden requests that bypass gateway security controls.

Why are API gateways more vulnerable to request smuggling than web servers?

Gateways multiplex clients over shared backend connections, enforce all security at one layer, and frequently downgrade HTTP/2 to HTTP/1.1, creating parsing mismatches.

Can HTTP/2 prevent request smuggling attacks?

HTTP/2 end-to-end eliminates the Content-Length vs. Transfer-Encoding ambiguity. However, gateways that downgrade to HTTP/1.1 for backends reintroduce the vulnerability.

What are the most common requests smuggling payloads to test?

Start with CL.TE and TE.CL payloads using conflicting headers. Escalate to obfuscated Transfer-Encoding variations and H2.CL downgrade payloads.

How does request smuggling relate to the OWASP API Security Top 10?

Request smuggling falls under API8:2023 (Security Misconfiguration), since misconfigured parsing and inconsistent HTTP handling between proxy layers create the conditions attackers exploit.