Web Cache Poisoning and HTTP Request Smuggling: Principles, Attack Scenarios, and Defenses

This article introduces two security vulnerabilities that allow attackers to affect user behavior without directly contacting the backend: Web Cache Poisoning and HTTP Request Smuggling. Both vulnerabilities exploit misconfigurations or inconsistencies in intermediate middleware (e.g., CDNs, reverse proxies) and require proper configuration and secure application design to detect and mitigate.

1. Web Cache Poisoning Attack Principles and Scenarios

1.1 What is a cache?

Cache technology reduces latency and server load by storing responses. Companies may use software such as Varnish or rely on CDNs like Cloudflare. This article focuses on caches deployed in front‑end services (CDNs), not on browser or DNS caches.

1.2 How does a cache work?

Front‑end proxy servers cache responses based on a “cache key”. When a subsequent request matches the same key, the cached response is returned without contacting the origin server. The figure below illustrates a scenario where the cache key (highlighted in red) causes User B to receive the cached response generated for User A.

1.3 How is cache poisoning implemented?

When an attacker’s request uses the same cache key as a legitimate user but contains malicious content that is reflected in the response, the poisoned response is cached. Subsequent legitimate users receive the malicious response. For example, if an application concatenates the Host header into a JavaScript URL, an attacker can inject a malicious domain (e.g., hack.com ) and cause victims to load attacker‑controlled scripts, similar to XSS.

Attackers can also craft requests that cause the cached response to redirect to non‑standard ports (e.g., 1337), rendering the service unusable for other users.

Extended Learning – Determining Cache‑Key Coverage

To verify the existence of a cache key, check for cache‑related HTTP headers, observe changes in dynamic content, compare response times, or look for third‑party cache‑control headers. To locate the coverage area, modify a request (A → B) and see whether B receives A’s cached response; if so, the changed part is not part of the cache key. Conversely, if the cache is missed, the changed part is part of the key. Specific headers such as Pragma: akamai-x-get-cache-key can also reveal the key.

2. Web Cache Poisoning Defense Measures

2.1 Disable caching where possible

The strongest mitigation is to turn off caching entirely. When static content can be clearly identified, only that content should be cached.

2.2 Avoid reflecting request inputs directly in responses

Identify inputs that are not part of the cache key and either strip them before caching or include them in the cache key. Tools like Param Miner can help audit pages for such inputs.

3. HTTP Request Smuggling Attack Principles and Scenarios

3.1 Basic principle

RFC 2616 §4.4 states that when both Content‑Length and Transfer‑Encoding are present, the Content‑Length must be ignored. Many implementations ignore this rule, leading to ambiguity in request boundaries. If a front‑end server and a back‑end server use different length‑determination rules, the tail of one request can be interpreted as the start of the next request, creating a smuggling vulnerability.

Various combinations of length‑determination produce different attack scenarios (illustrated below).

3.2 How Content‑Length and Transfer‑Encoding define body length

Each character occupies one byte; CRLF counts as two bytes. Content‑Length specifies the total byte count of the body.

Content‑Length example

POST /search HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11
q=smuggling

In chunked encoding, the body consists of a series of length lines followed by the data, ending with a zero‑length chunk.

Transfer‑Encoding: chunked example

POST /search HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded Transfer-Encoding: chunked
b
q=smuggling
9
q=smuggle
0
[
]
[
]

3.3 Attack execution

Two representative patterns are demonstrated: CL‑TE (Content‑Length on the front‑end, Transfer‑Encoding on the back‑end) and TE‑CL (the opposite).

CL‑TE

The front‑end server uses Content‑Length to determine the request length, while the back‑end parses the body as chunked. An attacker sends a request where the front‑end believes the body ends after six characters (including the terminating zero and CRLF), but the back‑end treats the remaining “G” as the start of the next request. When a victim’s request follows on the same TCP connection, the back‑end concatenates the stray “G” to the victim’s request, turning it into “GGET”.

TE‑CL

Here the front‑end accepts the whole chunked body, while the back‑end uses Content‑Length to split the body. The first part is delivered to the application, and the remainder is taken by the victim’s subsequent request, allowing the attacker to hijack the victim’s method, headers, and parameters.

3.4 Effects of HTTP request smuggling

An attacker can capture other users’ requests. For example, if a vulnerable comment endpoint ( /post/comment ) echoes request data, the attacker can smuggle a comment request that includes the victim’s request (including cookies) as part of the comment body, effectively leaking the victim’s request to the attacker.

Pitfall

If the victim’s request contains an ampersand (&), it is interpreted as a POST parameter separator, truncating the captured comment content at the first ampersand.

4. HTTP Request Smuggling Defense Measures

4.1 General mitigations

Disable TCP connection reuse between the front‑end and back‑end.

Adopt HTTP/2, which eliminates ambiguous request‑boundary parsing.

Ensure both front‑end and back‑end run the same web server software to guarantee consistent boundary handling.

4.2 Practical considerations

Disabling connection reuse can increase backend load, and HTTP/2 adoption may be limited. Ultimately, the root cause is inconsistent implementations; therefore, enforce identical request‑boundary logic across all layers.

5. Practical Resources

Web Cache Poisoning Lab (PortSwigger)

HTTP Request Smuggling Lab (PortSwigger)

6. Conclusion

Web cache poisoning and HTTP request smuggling are under‑recognized yet high‑impact vulnerabilities. Both stem from middleware misconfiguration rather than application logic, making detection through normal business‑logic testing difficult. Cache poisoning can affect all users sharing a cache, while request smuggling can hijack arbitrary requests on a persistent TCP connection. Because they do not require direct attacks on the backend or the victim’s device, they represent critical risks that security and operations teams must prioritize.