CORSMiddleware does not provide explicit origin although client credential is present

[gyusang]

When sending a CORS request with credentials, wildcard origin is rejected by the standard.

The fifth row of the Notes column in [1] says,

If credentials mode is "include", then Access-Control-Allow-Origin cannot be *.

[1] also says,

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.

Therefore, the server should check if any credentials exist inside the request and provide appropriate Access-Control-Allow-Origin to make CORS requests succeed.

---

Credentials are HTTP cookies, TLS client certificates, and authentication entries (for HTTP authentication). ([2])

HTTP cookies are already checked in the current version, so TLS client certificates (mTLS) and authentication entries support should be added.

starlette/starlette/middleware/cors.py

Lines 164 to 165 in 31164e3

	if self.allow_all_origins and has_cookie:
	self.allow_explicit_origin(headers, origin)

An authentication entry (...) are tuples of username, password, and realm, used for HTTP authentication (...), and associated with one or more requests. ([3])

Authentication entries used for HTTP authentication are associated using Authorization headers ([4]).

---

Thus, we need to respond with explicit(not *) Access-Control-Allow-Origin response headers when the request includes

1. HTTP Cookies
2. TLS client credentials
3. HTTP Authorization header

However, since this library creates a HTTP server, it cannot know the details of the TLS handshake unless the TLS termination proxy(e.g. uvicorn) provides such information. So the second case can be skipped (Using CORS with mTLS and a wildcard allow_origins would be very rare anyway).

Therefore I propose responding with explicit(not *) Access-Control-Allow-Origin response headers when Authorization request header is present and CORSMiddleware has allow_credentials option enabled.
Or, responding with explicit Access-Control-Allow-Origin response header when CORSMiddleware has allow_credentials option enabled (regardless of the Authorization header).

The second option allows supporting mTLS credentials being provided.

References:
[1] https://fetch.spec.whatwg.org/#cors-protocol-and-credentials
[2] https://fetch.spec.whatwg.org/#credentials
[3] https://fetch.spec.whatwg.org/#authentication-entries
[4] https://www.rfc-editor.org/rfc/rfc9110#section-11.6.2
[5] https://httpwg.org/specs/rfc7231.html#rfc.section.7.1.4

[iudeen]

I did some reading, I think it makes sense to include Authorization as well

[Kludex]

If a reporter doesn't provide references, you'll just make a maintainer spend time finding them.

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

[iudeen]

I checked Flask and Sanic's implementation. It seems like they don't have a logic to check cookie or authorization header explicitly. I guess that is what the spec sheet you had given above also suggests.

Ref:
corydolphin/flask-cors#202

https://github.com/ashleysommer/sanic-cors/blob/deaa19e61e6f689449cad0d83af077152f85da31/sanic_cors/core.py#L190

[gyusang]

I missed adding the reference. Thank you for finding the reference.

I modified the discussion to include references.

[gyusang]

django-cors-headers library always uses explicit origin when server has CORS_ALLOW_CREDENTIALS configured.
Reference:
https://github.com/adamchainz/django-cors-headers/blob/main/src/corsheaders/middleware.py#L154-L157