Re: no-vary: security - cache poisoning

On Sun, Jan 18, 2026, 20:39 Demi Marie Obenour <demiobenour@gmail.com>
wrote:

> 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.
>

The draft *does* use a separate header. It is *not* a Cache-Control option.
I mentioned it because another thread suggested it.

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?
>

The draft is about query parameters, so the ~user pattern isn't directly
applicable here.

But to answer your question, I would say "almost certainly yes", but I'm
not sure which specific CSP headers you're considering here.

David