If a resource allows credentials but omits Vary, shouldn't responses to non-CORS requests also contain Access-Control-Allow-Credentials?

[jub0bs]

While completing the test suite of my CORS middleware library, I ran into an interesting case. The section entitled CORS protocol and HTTP caches says the following:

[...] if Access-Control-Allow-Origin is set to * or a static origin for a particular resource, then configure the server to always send Access-Control-Allow-Origin in responses for the resource — for non-CORS requests as well as CORS requests — and do not use Vary.

However, in the case of a resource that

• systematically includes Access-Control-Allow-Origin: https://example.com in all responses,
• omits the Vary header (as explained above), but
• happens to allow credentials,

shouldn't responses to non-CORS requests also contain Access-Control-Allow-Credentials: true? Otherwise,

• a response to a non-CORS request lacking that header could get cached, and
• that cached response could subsequently get served for credentialed CORS requests from https://example.com.

This situation would unduly cause the CORS check to fail (at step 8). Unless I'm missing something, perhaps this consideration deserves a mention in the standard.

[annevk]

Perhaps we should update this advice to talk about the Sec-Fetch-Mode request header instead.

[jub0bs]

@annevk Wouldn't it be premature? My understanding is that Fetch Metadata will eventually get merged into the Fetch standard. Correct? Until then, though, I'm not sure the Fetch standard should reference Fetch Metadata Request Headers like Sec-Fetch-Mode.

[jub0bs]

Now that I think about it, a similar consideration involves the Access-Control-Expose-Headers. In the case of a resource that

• systematically includes Access-Control-Allow-Origin: https://example.com in all responses,
• omits the Vary header (as explained above),
• wishes to expose response headers,

the Access-Control-Expose-Headers header should likely be included in all responses, i.e. also to non-CORS requests.

[annevk]

@jub0bs Fetch already integrates with Fetch Metadata. While we could certainly supplant that specification, that's not a stated goal at the moment.

[jub0bs]

@annevk

Perhaps we should update this advice to talk about the Sec-Fetch-Mode request header instead.

What do you have in mind?

[jub0bs]

@annevk I'd like to revive this issue and, if we can come to an understanding, submit a PR for it. By #1601 (comment), I'm guessing you meant replacing

However, if Access-Control-Allow-Origin is set to * or a static origin for a particular resource, then configure the server to always send Access-Control-Allow-Origin in responses for the resource — for non-CORS requests as well as CORS requests — and do not use Vary.

by something like

However, if CORS-response headers (Access-Control-Allow-Origin and/or Access-Control-Allow-Credentials and/or Access-Control-Expose-Headers) are set to static values for a particular resource, then configure the server to

• always send those headers in responses to CORS requests for the resource but omit them in responses to non-CORS requests for the resource,
• always list Sec-Fetch-Mode in Vary in responses for the resource, both for non-CORS requests as well as CORS requests, and
• do not list Origin in Vary.

Or did you have something else in mind?

With the alternative approach I outline above, responses to non-CORS requests would be leaner and wouldn't give away that the resource is configured for CORS. One possible downside is increased logic complexity.

[annevk]

I think most of the section would have to be rewritten around Vary: Sec-Fetch-Mode as opposed to Vary: Origin. And it would probably also have to be run past some people deploying this kind of thing on a large scale.

[jub0bs]

@annevk Thanks for your reply. What would be the best way to get those people's input? Here or on the WHATWG's Matrix?