Re: no-vary: security - cache poisoning

On Mon, Jan 19, 2026, at 11:40, David Benjamin wrote:
> Ah, because it crosses resource boundaries? Hmm. I suppose a deployment 
> might have tried to draw boxes where the response generator for one set 
> of resources is allowed to send arbitrary headers and is assumed to not 
> influence what happens with another set of resources, and the 
> deployment puts different query parameters for the same path in 
> different distrusting boxes.

So the risk inherent in this proposal is that there are servers out there that pass requests to mutually-distrustful actors based solely on query parameters.

Imagine that you had dispatch within your server that didn't use the usual path hierarchical arrangement.  Rather than have app A and app B on /a and /b respectively, you had a URL parameter like this /whatever?app=a or /whatever?app=b&other=parameters

In that case, No-Vary-Search is a way for these apps to attack each other.  Either can poison the other's cache.

But David is right to ask whether there are other ways these apps are busted.  Origin and site isolation on the web are fine, but those barriers come down when mutually distrustful apps share a scope.  Sub-origin isolation has been proposed many times, but only ever as a redundant defense; the apps really need to trust each other if they share an origin.

A server that operates this way places a lot of responsibility on the shared component that both apps trust.  That component might be somewhat surprised by No-Vary-Search, undermining the protections it has.  But those were already fragile.

> Skimming the draft I see it says something vaguely to this effect in 
> security considerations.
> https://www.ietf.org/archive/id/draft-ietf-httpbis-no-vary-search-03.html#name-security-considerations

If we care, those could be better.  But I don't think that I care.

Received on Monday, 19 January 2026 00:56:24 UTC