CORS requests with credentials should forbid `*`

[ehmicky]

The standard forbids using * in the Access-Control-Allow-Origin, Access-Control-Expose-Headers, Access-Control-Allow-Methods, or Access-Control-Allow-Headers response header, if the Access-Control-Allow-Credentials request header is set to true.

https://fetch.spec.whatwg.org/#cors-protocol-and-credentials

https://fetch.spec.whatwg.org/#http-new-header-syntax

Right now, this module allows it. In fact, it does it by default if the credentials option is set to true.

Instead, it could either:

• Throw an error
• Not set CORS response headers, i.e. rejecting the CORS request
• Use the Origin request header, if specified. The Vary: Origin response header would need to be set too then.

[shawnleetw]

Hi, I have a few years of web dev experiences including Express.

But I'm new to open-source contribution and would like to find a chance to start. Anything I could help here?

[ctcpip]

That's not entirely true... it's only not allowed if the request's credentials mode is "include". The credentials option in this library determines whether to set the response header.

In any case, where this gets tricky is that we cannot know in all cases what the credentials mode/intent is. For example, if cookies are sent, those cookies are not necessarily credentials. We would not want to break users just based on the presence of arbitrary cookies alone.

It's also probably not prudent for the framework itself to be checking client certificates in order to determine header content.

It might be safe to check authorization headers. e.g. if auth header(s) are present, then do something different. (FWIW, I haven't actually looked into what the current behavior is in this scenario.)

[jub0bs]

Relevant: https://jub0bs.com/posts/2023-02-08-fearless-cors/#6-treat-cors-as-a-compilation-target