HIGH Authentication & Authorization

Request Smuggling in APIs

Scan your API for request smuggling

What is Request Smuggling?

Request smuggling is a protocol-level attack where an attacker manipulates how an HTTP request is parsed by different components in the request processing chain. The core issue arises when front-end and back-end servers interpret the same HTTP request differently, allowing attackers to hide malicious payloads that only the back-end server processes.

The vulnerability exploits inconsistencies in how servers handle Content-Length and Transfer-Encoding headers. For example, a front-end server might use Content-Length to determine where a request ends, while the back-end uses Transfer-Encoding. This mismatch creates ambiguity about request boundaries, enabling attackers to smuggle additional requests inside the body of an initial request.

Classic HTTP smuggling examples include:

  • CL.TE: Front-end uses Content-Length, back-end uses Transfer-Encoding
  • TE.CL: Front-end uses Transfer-Encoding, back-end uses Content-Length
  • TE.TE: Both use Transfer-Encoding but handle chunked encoding differently

In API contexts, request smuggling can be particularly dangerous because APIs often process multiple requests concurrently and may have complex routing logic between load balancers, API gateways, and application servers.

How Request Smuggling Affects APIs

Request smuggling in APIs can lead to several severe security consequences. Attackers can exploit this vulnerability to bypass authentication, access unauthorized resources, or even poison application state across multiple users.

Common API attack scenarios include:

  • Authentication bypass: An attacker sends a smuggling request where the first part appears legitimate (passing authentication), but the second part contains malicious API calls that inherit the authenticated context
  • Data leakage: Smuggled requests can access sensitive data from other users' sessions or internal API endpoints
  • Request hijacking: An attacker's request can be processed as part of another user's legitimate API call, leading to unauthorized actions
  • Denial of service: Smuggled requests can tie up back-end resources or cause application crashes

Consider an e-commerce API where an attacker smuggles a request to modify another user's order inside a legitimate product search request. The front-end server processes the search, but the back-end executes the order modification, potentially changing shipping addresses or payment methods without authorization.

How to Detect Request Smuggling

Detecting request smuggling requires systematic testing of how your API infrastructure handles ambiguous HTTP requests. Here are key detection methods:

  1. Header manipulation testing: Send requests with conflicting Content-Length and Transfer-Encoding headers to observe how servers respond
  2. Boundary testing: Use carefully crafted payloads that exploit potential parsing differences between front-end and back-end components
  3. Timing analysis: Monitor response times and patterns that might indicate request processing anomalies
  4. Response inspection: Look for responses that contain data from unexpected requests or show signs of request mixing

middleBrick automatically detects request smuggling vulnerabilities through black-box scanning. The scanner sends specially crafted HTTP requests that test for common smuggling patterns across your API endpoints. It analyzes responses for indicators like:

  • Unexpected status codes or error messages
  • Response bodies containing data from other requests
  • Timeouts or connection resets that suggest parsing issues
  • Headers that reveal backend processing behavior

The scanner tests multiple smuggling variants including CL.TE, TE.CL, and TE.TE scenarios, providing detailed findings with severity ratings and specific remediation guidance for each detected vulnerability.

Prevention & Remediation

Request smuggling has caused significant security incidents across major platforms. In 2019, a critical vulnerability in HTTP/2 implementations allowed attackers to perform request smuggling attacks that bypassed authentication in several popular web frameworks.

The CVE-2019-10744 vulnerability affected multiple HTTP/2 servers, allowing attackers to inject requests that were processed by backend servers without proper validation. This vulnerability impacted applications using Node.js, Go, and other languages that implemented HTTP/2 parsing.

Cloudflare documented a request smuggling issue in 2020 where inconsistent handling of Transfer-Encoding headers between their edge servers and origin servers allowed attackers to access internal APIs and customer data. The vulnerability affected multiple SaaS platforms using Cloudflare's services.

Financial services APIs have been particularly vulnerable to smuggling attacks because they often involve complex microservices architectures with multiple API gateways and load balancers. Attackers have exploited these vulnerabilities to manipulate transaction processing and access unauthorized account information.

The OWASP API Security Top 10 now explicitly includes request smuggling as a critical vulnerability category, emphasizing the importance of proper HTTP request handling in API security. Organizations handling sensitive data or financial transactions should prioritize request smuggling testing as part of their security assessment programs.

Scan for request smuggling View all security checks

Frequently Asked Questions

How is request smuggling different from HTTP request splitting?
Request smuggling and HTTP request splitting are related but distinct attacks. Request splitting involves adding CRLF sequences to create multiple requests from a single HTTP message, typically exploiting header injection vulnerabilities. Request smuggling is more sophisticated—it exploits inconsistencies in how different servers parse the same request, allowing attackers to hide additional requests inside the body of an initial request. Smuggling attacks don't require CRLF injection and can work even when strict header validation is in place.
Can request smuggling affect GraphQL APIs?
Yes, GraphQL APIs are vulnerable to request smuggling, often in more subtle ways than REST APIs. Since GraphQL typically uses POST requests with JSON bodies, attackers can exploit smuggling by manipulating Content-Length headers or using Transfer-Encoding to smuggle requests that the GraphQL parser processes differently than the HTTP layer. The nested nature of GraphQL queries can also create additional parsing ambiguities that attackers might exploit.
Does HTTPS protect against request smuggling?
No, HTTPS does not protect against request smuggling. The vulnerability exists at the HTTP protocol level, which is encrypted by TLS. Once the TLS connection is terminated (at the load balancer, reverse proxy, or application server), the HTTP request is parsed in plaintext. The attack exploits how different components in your infrastructure interpret that plaintext HTTP request, so encryption doesn't prevent the vulnerability.