Re: no-vary: security - cache poisoning

On Sun, Jan 18, 2026, 14:42 Julian Reschke <julian.reschke@gmx.de> wrote:

> Am 18.01.2026 um 18:39 schrieb David Benjamin:
> > Wouldn't such an intermediary also be able to poison a cache by sending
> > other caching headers wrong or the wrong content? I think that's just
> > generally part of the threat model for caches and intermediaries, unless
> > I'm missing something here
>
> Probably.
>
> What's new (?) is that the cache can cause clients to store responses
> under the incorrect key. Does that make a difference? Dunno.
>

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.

I suspect such a deployment is thoroughly a lost cause. If the distrusting
components can send arbitrary headers, we already have other origin-wide
headers like cookies and HSTS. Certainly anything that expects to serve to
a browser cannot usefully work this way. There, resources within an origin
can already influence each other in all manner of ways.

(If the distrusting components can't send arbitrary headers, they
presumably aren't able to send this new header, so it's moot. I suppose
this is a minor point towards not using Cache-Control. Maaaaybe you've got
distrusting components that are fairly limited, but are able to send
Cache-Control because, up to now, you assumed Cache-Control was scoped to
one cache key.)

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

David