1565550 - In some cases, CORS fetch result reused (including CORS Allow-* headers) when fetched from another origin, despite `Vary: Origin` header, breaking CORS

Status: RESOLVED INVALID

(Core :: Networking: HTTP, defect, P2)

Description

[michiel]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36

Steps to reproduce:

See https://michielbdejong.com/blog/23.html

Actual results:

See https://michielbdejong.com/blog/23.html

Expected results:

See https://michielbdejong.com/blog/23.html

Comment 1

[michiel]

Chrome bug about the same topic is here: https://bugs.chromium.org/p/chromium/issues/detail?id=983532

Comment 2

[:Gijs (he/him)]

From the blogpost:

https://site-one.5apps.com
https://site-two.5apps.com
https://site-three.5apps.com
https://site-four.5apps.com

The thing that's going wrong is that in the site-one/site-two case, the browser ignores the Vary: Origin header, and caches the result from site-one in the http cache, including the Access-Control-Allow-Origin: https://site-one.5apps.com header. Therefore, the cross-origin request from site-two.5apps.com is blocked. In this case, doing just a GET, this could be worked around using Access-Control-Allow-Origin: *, but for POST and other verbs, the server needs to echo the origin from the HTTP request's Origin there. For some mysterious reason, the same thing does not go wrong for site-three/site-four! :)

(in future, when filing bug reports, please put at least some actual description of the issue into the initial comment - not just links)

Comment 3

[:Gijs (he/him)]

Not sure if cache is better than DOM: Networking for CORS-related things - Anne, do you have thoughts here?

Comment 4

[Anne (:annevk)]

CORS is normally DOM: Networking, but this seems like an issue with the cache not supporting Vary. This will probably also be fixed once we fix bug 1536058 however.

Comment 5

[michiel]

Update: See https://bugs.chromium.org/p/chromium/issues/detail?id=983532, it turns out that this works as follows:

I had assumed that if you put a Vary header on a 200, then the browser would not attempt to use that cached data if that Vary header is not satisfied. In reality, it's slightly more subtle: If the Vary header is not satisfied, then the browser will always do a new request to the server, but that request can still be conditional, and if the new response is a 304, than the cached version of the document will still be used!

The server we were testing against had a bug where its 304 responses are lacking CORS headers, and so that's what caused the confusion.

This does mean that if a server varies its responses based on for instance Origin, then it should also vary its ETags along with that. Just setting the Vary header is not enough to prevent cache sharing, actually varying the ETag values is also important.