Re: no-vary: security - cache poisoning

On 1/18/26 19:55, Martin Thomson wrote:
> 
> 
> 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.

I agree that this does place a lot of responsibility on this
component.  However, my understanding is that serving static files
from mutually-distrusting users from the same origin is both safe and
extremely common.  One just needs to ensure that the files cannot
be interpreted as JavaScript or other unsafe MIME types and use a
suitable Content-Security-Policy.

Normally, such static file servers don't allow setting headers.
However, one might well want to allow those who upload files to
be able to control caching of them.  One way is to allow passing
a Cache-Control header.  Including No-Vary-Search in Cache-Control
would make such servers vulnerable to a cache poisoning attack.

Using a separate header seems like a safer option.

P.S.: There are even sites that allow multiple mutually-distrusting
users to provide static HTML from their home directories.  This is the
classic "https://a.example.com/~user/index.html" pattern.  Are there
any exploits possible if appropriate Content-Security-Policy headers
are set?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)