Http Request Smuggling in APIs

HTTP request smuggling is a technique that exploits discrepancies in how front-end servers (reverse proxies, load balancers, CDNs) and back-end servers parse HTTP requests. When two servers in a chain disagree on where one request ends and the next begins, an attacker can "smuggle" a hidden request inside what appears to be a single legitimate one.

The root cause lies in the HTTP/1.1 specification's two mechanisms for indicating the length of a request body:

• Content-Length header: specifies the body size in bytes
• Transfer-Encoding: chunked header: signals that the body is sent in chunks, each prefixed with its size in hexadecimal

When both headers are present in the same request, RFC 7230 (Section 3.3.3) states that Transfer-Encoding must take precedence. In practice, many servers handle this differently, creating three classic smuggling variants:

In API architectures, where requests typically pass through multiple proxy layers before reaching an application server, request smuggling creates a particularly dangerous attack surface.

APIs are high-value targets for request smuggling because they typically sit behind reverse proxies and API gateways that perform authentication, rate limiting, and routing. A successful smuggling attack can bypass all of these controls.

Here is a concrete CL.TE smuggling attack against an API endpoint:

POST /api/v1/search HTTP/1.1
Host: api.example.com
Content-Length: 44
Transfer-Encoding: chunked

0

GET /api/admin/users HTTP/1.1
Host: api.example.com

The front-end proxy reads the Content-Length and forwards the entire payload as one request. The back-end server processes the Transfer-Encoding, sees the 0\r\n chunk terminator, and treats everything after it as the start of a new request. The smuggled GET /api/admin/users request executes on the back-end without passing through the gateway's authentication checks.

Attackers can leverage this to:

• Bypass authentication and authorization: smuggled requests skip the API gateway's security middleware entirely
• Poison web caches: force a cache to store attacker-controlled content under a legitimate URL, affecting all subsequent users
• Hijack other users' requests: the smuggled prefix gets prepended to the next legitimate user's request, capturing their credentials or session tokens
• Bypass rate limiting: smuggled requests are invisible to the rate limiter running on the front-end
• Access internal endpoints: reach admin APIs, health checks, or debug endpoints that are restricted at the proxy layer

Detecting request smuggling is challenging because the vulnerability exists in the interaction between two systems, not in either one alone. Manual detection typically involves sending ambiguous requests and observing timing differences or response anomalies.

A basic CL.TE detection probe works by sending a request where the chunked body intentionally delays processing:

POST /api/v1/healthcheck HTTP/1.1
Host: api.example.com
Content-Length: 6
Transfer-Encoding: chunked

0

X

If the back-end uses Transfer-Encoding, it processes the 0 chunk terminator and waits for the next request. The leftover X causes a noticeable time delay or an error response, indicating a CL.TE desynchronization.

Signs that suggest an API may be vulnerable:

• The server sits behind a reverse proxy or load balancer (common in any production API)
• HTTP/1.1 is used between the proxy and the origin (HTTP/2 end-to-end mitigates most variants)
• The server does not reject requests containing both Content-Length and Transfer-Encoding
• Obfuscated Transfer-Encoding headers (extra whitespace, mixed case, line folding) are not normalized or rejected

middleBrick's automated scanning checks your API's behavior when presented with ambiguous HTTP framing. By submitting a URL to middleBrick, you get a risk score that reflects how your API and its infrastructure respond to these edge cases, alongside findings for 12 security categories including input validation and data exposure. You can run scans from the web dashboard, from your terminal with middlebrick scan <url>, or directly from your CI/CD pipeline using the middleBrick GitHub Action to catch regressions before they reach production.

Preventing HTTP request smuggling requires eliminating the parsing disagreements between front-end and back-end servers. The most effective strategies are:

1. Use HTTP/2 end-to-end. HTTP/2 has a binary framing layer with explicit length fields, eliminating the Content-Length vs. Transfer-Encoding ambiguity entirely. If your back-end supports HTTP/2, configure your reverse proxy to use it for upstream connections, not just client-facing.

2. Reject ambiguous requests. Configure your servers to return a 400 error when a request contains both Content-Length and Transfer-Encoding headers. In NGINX:

# nginx.conf — reject ambiguous requests
server {
    # Block requests with both Content-Length and Transfer-Encoding
    if ($http_transfer_encoding ~* "chunked" ) {
        set $te_present 1;
    }
    if ($content_length != "") {
        set $cl_present 1;
    }
    # Use a map or Lua module for compound conditions in production
}

A more robust approach using a Node.js middleware for your API:

// Reject requests with both Content-Length and Transfer-Encoding
function antiSmuggling(req, res, next) {
  const hasCL = req.headers['content-length'] !== undefined;
  const hasTE = req.headers['transfer-encoding'] !== undefined;

  if (hasCL && hasTE) {
    return res.status(400).json({
      error: 'Ambiguous request framing',
      detail: 'Requests must not contain both Content-Length and Transfer-Encoding'
    });
  }
  next();
}

app.use(antiSmuggling);

3. Normalize headers at the edge. Strip or normalize Transfer-Encoding headers with unusual formatting (extra whitespace, line folding, or unrecognized values) before forwarding to back-end servers.

4. Keep all servers updated. Many smuggling vulnerabilities arise from parser bugs fixed in subsequent releases. Ensure your proxy servers (NGINX, HAProxy, Apache) and application servers run current, patched versions.

5. Disable HTTP/1.1 connection reuse between proxy and back-end. If HTTP/2 end-to-end is not feasible, configuring the proxy to use separate connections for each request eliminates smuggling at the cost of some performance. In HAProxy, set option http-server-close.

To verify your fixes, run periodic scans with middleBrick. The Pro plan provides continuous monitoring on a configurable schedule with alerts via Slack, Teams, or email, so you are notified if a configuration change reintroduces the vulnerability.

HTTP request smuggling has caused significant security incidents across major platforms and infrastructure:

In 2020, security researcher James Kettle demonstrated request smuggling against numerous production systems, including infrastructure serving millions of users, showing how smuggled requests could poison CDN caches and steal user credentials. These were not theoretical attacks but working exploits against live systems.

For API-first organizations, the risk is compounded because APIs often serve as the sole interface for critical operations: payments, data access, and account management. A successful smuggling attack on a payment API could allow an attacker to modify transaction amounts, access other users' financial data, or bypass fraud detection systems entirely.

Regular security scanning is essential to catch these vulnerabilities before attackers do. middleBrick maps findings to compliance frameworks including OWASP API Security Top 10, PCI-DSS, and SOC 2, giving you both the technical detail and the compliance context needed to prioritize remediation.