9

Backend returns 

Access-Control-Allow-Headers: *

I have a request like

fetch('url-here', {
    // ...
    headers: {
        'X-Auth': token,
    }
})

It works in Chrome but for Firefox I'm getting

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at <...cut...>. (Reason: missing token ‘X-Auth’ in CORS header ‘Access-Control-Allow-Headers’ from CORS preflight channel).[Learn More] Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at <...cut...>. (Reason: CORS request did not succeed)

sideshowbarker
  • 81,827
  • 26
  • 193
  • 197
skyboyer
  • 22,209
  • 7
  • 57
  • 64
  • 1
    Might be related to this: https://stackoverflow.com/questions/24371734/firefox-cross-origin-request-blocked-despite-headers – Rence Feb 13 '19 at 09:31
  • 1
    @Sirence or this: https://stackoverflow.com/questions/52750589/access-control-allow-headers-set-to-but-still-failing-in-firefox?noredirect=1#comment96123359_52750589 – skyboyer Feb 13 '19 at 09:32
  • 2
    Important note: when responding to a credentialed request, server must specify a domain, and cannot use wild carding: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Requests_with_credentials – Rence Feb 13 '19 at 09:34
  • Watch my answer in below url : https://stackoverflow.com/questions/56556415/access-control-allow-headers-is-being-ignored?answertab=active#tab-top – Sahil Bhalla Oct 07 '19 at 05:22

1 Answers1

7

The problem is, some browsers don’t yet allow * wildcards for Access-Control-Allow-Headers. Notably, Firefox 69 and earlier doesn’t. See https://bugzilla.mozilla.org/show_bug.cgi?id=1309358.

So to ensure you get expected behavior in all browsers, the Access-Control-Allow-Headers value you send back should explicitly list all the header names you actually need to access from your frontend code; e.g., for the case in the question: Access-Control-Allow-Headers: X-Auth.

One way you can make that happen without needing to hardcode all the header names is: Have your server-side code take the value of the Access-Control-Request-Headers request header the browser sends, and just echo that into the value of the Access-Control-Allow-Headers response header your server sends back.

Or else use some existing library to CORS-enable your server. Echoing the Access-Control-Request-Headers request-header value into the Access-Control-Allow-Headers response-header value is something most CORS libraries will typically do for you.

sideshowbarker
  • 81,827
  • 26
  • 193
  • 197
  • 2
    @zerkms I updated the spec URL to refer to the https://tc39.github.io/ecma262 location instead of the now-outdated https://www.ecma-international.org/ecma-262/9.0/ (ES2018) location. Current MDN policy is to always use the `{{SpecName('ESDraft', …)}}` macro for references to the ES spec (rather than using `{{SpecName('ES2018', …)}}` or any older ES spec versions). If you want to discuss that policy, the #mdn channel on irc.mozilla.org is a good place. Or https://discourse.mozilla.org/c/mdn – sideshowbarker Mar 29 '19 at 07:20
  • 1
    @zerkms Yeah it’s a bit of a judgement call but in the particular case of the https://developer.mozilla.org/en-US/docs/Web/JavaScript subtree, the call was made by Florian Scholz, who’s the designated maintainer for that. And his call is what I’ve mentioned here: that the spec references to the ES6 spec should all the https://tc39.github.io/ecma262 version. This came up also when added the spec URLs to the Browser Compatibility Data repo: https://github.com/mdn/browser-compat-data/pull/2983. For that we used https://tc39.github.io/ecma262 URLs exclusively. – sideshowbarker Mar 29 '19 at 07:37