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

[Vansh0204]

Hi sir, I have raised a PR for this issue. Could you please review it?

[jub0bs]

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

As @ctcpip pointed out, that premise is inaccurate. This instance of Jake Archibald's CORS playground may be enough to convince you.

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

Indeed, and this behaviour, though likely perceived as convenient by users of this library who don't know better, gives rise to insecure CORS middleware. There is a reason the Fetch standard forbids the use of the wildcard in conjunction with credentialed access: allowing it would be too dangerous; see

• https://portswigger.net/blog/exploiting-cors-misconfigurations-for-bitcoins-and-bounties
• https://jub0bs.com/posts/2023-02-08-fearless-cors/#6-treat-cors-as-a-compilation-target

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.

For reasons discussed above, the third option is inadequate (even if Vary is used).

The second option arguably violates the principle of least surprise: if a CORS config isn't valid, the library should tell the author of that config as early as possible instead of producing a dysfunctional middleware.

That leaves the first option, which is what I recommend. That is what I've implemented in my CORS library for Go.

---

@ctcpip

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.

Indeed. The following passage of the Fetch standard is relevant:

A request’s credentials mode is not necessarily observable on the server; only when credentials exist for a request can it be observed by virtue of the credentials being included. Note that even so, a CORS-preflight request never includes credentials.

Clearly, you cannot guess the credentialed nature of a request by inspecting the associated preflight request (if any), since the latter never carries credentials. But even in the case of an "actual" request (i.e. a non-preflight CORS request), the server cannot always tell whether such a request is credentialed. This instance of Jake Archibald's CORS playground offers an extreme example: under the assumption that you haven't created any cookies (or client-side certificates, etc.) associated with jakearchibald.com beforehand, the browser treats the resulting request as credentialed even though it carries no credentials whatsoever.