Omitting access-control-allow-headers in CORS / preflight response

Question

I’m having trouble finding information explaining what happens if the response to a preflight request or the response to the actual CORS request omits Access-Control-Allow-Headers. I have noticed that several sites say this header is required when the request includes Access-Control-Request-Headers.

I would like to allow CORS access to my API with any headers, so I’m wondering if omitting this header will do just that and allow all headers.

My API requires that you send an Authorization header containing an OAuth token and typically the client will also send a cookie. There are sites that say that using * for Access-Control-Allow-Headers only acts as a wildcard when Access-Control-Allow-Credentials is false.

This seems to put me in a bind since I want the CORS request to include credentials (the Authorization header and a cookie) but I also want to allow all headers. How can I make this work?

A secondary question is why would I want to restrict the request to an allowed set of headers? In my case the API is a GET which makes no changes on the server. I want allowed origins to always be able to retrieve this information. Under what circumstances would the headers they include play into that?

Answer 1

I’m having trouble finding information explaining what happens if the response to a preflight request or the response to the actual CORS request omits Access-Control-Allow-Headers. I have noticed that several sites say this header is required when the request includes Access-Control-Request-Headers.

Those sites are correct: if the preflight request contains an Access-Control-Request-Headers header, then the response to that request must, at the very least, contain an Access-Control-Allow-Headers header, or CORS preflight will fail. The actual header value required for CORS preflight to succeed will differ on the basis of which header names were specified in the preflight request.

I would like to allow CORS access to my API with any headers, so I’m wondering if omitting this header will do just that and allow all headers.

No, omitting the Access-Control-Allow-Headers header in the response to the preflight request does not count as a pass.

My API requires that you send an Authorization header containing an OAuth token and typically the client will also send a cookie. There are sites that say that using * for Access-Control-Allow-Headers only acts as a wildcard when Access-Control-Allow-Credentials is false.

Close, but imprecise. Rather, you cannot use the wildcard for Access-Control-Allow-Headers if you use Access-Control-Allow-Credentials: true. See https://fetch.spec.whatwg.org/#http-new-header-syntax

This seems to put me in a bind since I want the CORS request to include credentials (the Authorization header and a cookie) but I also want to allow all headers. How can I make this work?

In that case, you cannot use the wildcard. You only have one way: take all the header names listed in the preflight request's Access-Control-Request-Headers header and reflect them in the response's Access-Control-Allow-Headers header.

A secondary question is why would I want to restrict the request to an allowed set of headers? In my case the API is a GET which makes no changes on the server. I want allowed origins to always be able to retrieve this information. Under what circumstances would the headers they include play into that?

I may be missing something, but I don't think this is problematic if the set of allowed origins is finite. However, if you allow arbitrary origins, you probably shouldn't allow arbitrary headers on authenticated endpoints. In particular, allowing the Authorization for arbitrary origins opens the door to client-side, distributed brute-force of Bearer tokens (or whatever the Authorization normally contains); more about that in https://github.com/whatwg/fetch/issues/251#issuecomment-209265586