My client sends requests authenticated via the following header:
Authorization: Bearer some-token
Will including the following header in responses make things not work?
Access-Control-Allow-Credentials: false
My client sends requests authenticated via the following header:
Authorization: Bearer some-token
Will including the following header in responses make things not work?
Access-Control-Allow-Credentials: false
First, be aware that false
isn't a remarkable value for the Access-Control-Allow-Credentials
header. According to the Fetch standard, the only remarkable value is true
(lowercase). Including the header in a response with a value other than true
is functionally equivalent to omitting that header from the response. The question then becomes:
Does
Access-Control-Allow-Credentials: true
need to be present in responses to CORS requests for things to work?
Access-Control-Allow-Credentials: true
is only required in responses to cross-origin credentialed requests, e.g. requests initiated from a different Web origin with
withCredentials = true
with the XmlHttpRequest
API, orcredentials: 'include'
with the Fetch API.The term credentials, in this context, refers to browser-managed credentials or ambient authority, i.e. things that the browser automatically attaches to requests (when applicable): cookies, client-side TLS certs, regular Basic
auth, etc.
If your client includes an Authentication
header (regardless of the authentication scheme used: Basic
, Bearer
, etc.) to an otherwise non-credentialed request, the presence of Access-Control-Allow-Credentials: true
in the corresponding response is irrelevant. This instance of Jake Archibald's CORS playground may be sufficient to convince you.
However, a necessary condition for things to work is that the response to the preflight request include an Access-Control-Allow-Headers
header that lists, possibly among other request-header names, Authorization
(case-insensitive), e.g.
Access-Control-Allow-Headers: Authorization