How it works
Proxies, caches and origin servers each parse and key requests independently. Where those interpretations diverge, an attacker can desynchronise a shared connection, poison a shared cache entry, or cause a browser to issue an authenticated request the user never intended.
Attacks that reach other people
Most web vulnerabilities affect the attacker's own session. The three in this article are grouped because they do not: each one lets an attacker influence what a different user experiences.
Request smuggling injects a request into a connection another user is sharing. Cache poisoning changes a stored response that will be served to everyone. Cross-site request forgery causes a victim's own browser to perform an action using credentials the attacker never sees.
That property changes how they should be prioritised. A flaw an attacker can only turn against themselves is a lower priority than one that turns every visitor into a victim, and these are routinely rated on the former basis because the request appears well formed in isolation.
Request smuggling
HTTP allows a message body's length to be expressed in more than one way, and a request carrying conflicting indications is ambiguous. The specification says to reject it. Implementations historically differed on which indication wins.
Where a front-end proxy and a back-end origin resolve that ambiguity differently, they disagree about where one request ends and the next begins. The proxy forwards what it believes is one request; the origin reads it as one request plus the beginning of another, which then prefixes whatever genuinely arrives next on that connection — a request belonging to a different user.
The consequences are severe and unusually broad: capturing another user's request including their credentials, forcing a response intended for them, or bypassing front-end access controls because the smuggled portion never passed through them.
The defence is architectural rather than a rule. Terminate and normalise at one hardened edge, re-emit the request in unambiguous form, and reject conflicting framing outright rather than choosing an interpretation. Keeping proxy and origin on aligned, patched implementations reduces the divergence that makes it possible.
Cache poisoning and deception
A cache stores a response and serves it for subsequent matching requests. Which requests match is decided by the cache key, and the key rarely includes everything that influenced the response.
If an input outside the key changes what the origin returns, an attacker can send a request that produces harmful content and have it stored against the key that ordinary users will match. The next visitors receive it. A single request has altered the site for everyone.
Cache deception is the mirror image: the attacker persuades the cache to store a response that was personal to a victim. Requesting a private page with a suffix that makes it resemble a static asset can cause a cache to store it as public, after which the attacker retrieves someone else's data from the cache.
The rules are unglamorous and effective. Every input capable of changing a response must be part of the key or must be stripped before the origin sees it. Responses that vary by user must be explicitly uncacheable, decided by what the response contains rather than by what the URL looks like. And normalisation must happen before the key is computed, so two spellings of the same path cannot occupy different entries.
Cross-site request forgery
CSRF exploits the browser's willingness to attach credentials to any request bound for a site, regardless of what caused it. A page on another origin triggers a request to yours; the browser attaches the session cookie; the application sees an authenticated request and performs the action.
The attacker never reads the response and never obtains the session. They do not need to — the action itself is the objective, which is why CSRF matters on state-changing endpoints and is largely irrelevant on read-only ones.
SameSite cookie defaults have substantially reduced exposure by preventing cookies from riding on most cross-site requests, and this is genuine progress. It is not complete: the protection depends on browser behaviour and configuration, some request shapes are still permitted, and same-site subdomains may not be as trustworthy as the setting implies.
The durable pattern remains a token bound to the session and required on every state-changing request, combined with Origin validation. And state-changing operations should never be reachable by GET — a request that changes something in response to a navigation is exploitable by a link.
Detection
These are unusually hard to observe from application logs alone, because the individual requests look ordinary.
- Compare request counts between proxy and origin. A persistent discrepancy is one of the few reliable smuggling signals.
- Alert on responses served from cache that carry user-specific markers such as personalised greetings or account identifiers.
- Track cache hit ratio per route; an unexpected rise on a route that should be private is worth investigating immediately.
- Log rejected CSRF validations. A rate of zero usually means the check is absent rather than that no attempts occur.
- Watch for requests whose Origin does not match any deployed front end.
Also known as
What defenders may observe
- Proxy and origin logs disagree about request counts
- Users receive responses intended for someone else
- Private responses show cache hits
- Rare headers or path forms change cached output
- State-changing requests arrive without origin or token validation
Prevention and mitigation
- Normalise every request at one hardened edge and reject ambiguous framing
- Keep proxy and origin HTTP parsing aligned and patched
- Define cache keys that include every input capable of changing the response
- Never cache responses that vary by user
- Require SameSite cookies and anti-CSRF tokens for state-changing requests
- Validate the Origin header on sensitive endpoints and re-authenticate for high-risk actions
Initial response priorities
- Contain the vulnerable route or feature.
- Preserve requests, traces and affected records.
- Fix the root control failure, test adjacent paths and rotate exposed secrets.
Use your approved incident-response plan and adapt decisions to your environment. This is educational guidance, not a substitute for live incident leadership.