Although the OPTIONS returns * for Allow-Headers I'm getting the following CORS response.

Access to XMLHttpRequest at 'https://example1.com' from origin 'https://example2.net' has been blocked by CORS policy: Request header field x-requested-with is not allowed by Access-Control-Allow-Headers in preflight response.

While the OPTION request looks like this:

Request Method: OPTIONS
Status Code: 204 

Request headers:

Access-Control-Request-Headers: x-requested-with
Access-Control-Request-Method: POST
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36

Response headers:

access-control-allow-credentials: true
access-control-allow-headers: *
access-control-allow-methods: GET,POST
access-control-max-age: 86400
content-length: 0
content-type: text/plain charset=UTF-8
date: Wed, 12 Jun 2019 05:03:06 GMT
status: 204

Why do I get this CORS error? and how to avoid it?

  • Hello Roee and welcome to Security.SE. Please edit your question to include what you are actually trying to accomplish. Your question right now is a status, not an answerable question.
    – user163495
    Commented Jun 12, 2019 at 8:48

2 Answers 2


The Access-Control-Allow-Headers header does not support wildcards. You can only supply a list of actual headers that are allowed.

If you still want to allow all headers, you can make your web application look at which headers are present in the request and reflect all these in Access-Control-Allow-Headers.

  • 1
    "The Access-Control-Allow-Headers header does not support wildcards" This is only true when Access-Control-Allow-Credentials: true is sent. Without that header, wildcards in Access-Control-Allow-Headers work fine.
    – Ajedi32
    Commented Sep 9, 2021 at 16:41

Things have changed since this question was asked and answered. Support for Access-Control-Allow-Headers: * in responses to non-credentialed requests was added to the Fetch standard in 2017. The feature was implemented in major browsers shortly after that. See the relevant section of the MDN page about that response header:

The value "*" only counts as a special wildcard value for requests without credentials (requests without HTTP cookies or HTTP authentication information). In requests with credentials, it is treated as the literal header name "*" without special semantics. Note that the Authorization header can't be wildcarded and always needs to be listed explicitly.

  • 1
    Probably worth noting that in the OP's case specifically "without credentials" doesn't apply since access-control-allow-credentials: true is being sent in the response, so wildcards in Access-Control-Allow-Headers still won't work.
    – Ajedi32
    Commented Sep 9, 2021 at 16:51
  • @Ajedi32 True, but the accepted answer doesn't mention that the wildcard does work as expected for non-credentialed requests. Future visitors might be interested in learning that.
    – jub0bs
    Commented Sep 9, 2021 at 16:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .