Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Firefox not sending original Authorization header when fetch follows a redirect in 112.0

  • 8 replies
  • 0 have this problem
  • 1 view
  • Last reply by TyDraniu

more options

We've noticed that in Firefox 112.0 (maybe in 111.0? haven't tested yet...) when a `fetch` request with an `Authorization` header gets a `302` (or `307`, and probably any other redirect response code) and `redirect` is set to `follow`, the second request is made _without_ an `Authorization` header, which breaks our website.

In 110.0 this isn't an issue, and no warning is logged to tell us it's about to change.

I'm guessing this is a security change - could someone point me at the discussion that led to it being made? My feeling is that if the redirect is to the same origin as the original request sending the same `Authorization` header should be secure enough.

I'm wondering what the right mitigation is; we could follow redirects manually of course, but it's a pain.

We've noticed that in Firefox 112.0 (maybe in 111.0? haven't tested yet...) when a `fetch` request with an `Authorization` header gets a `302` (or `307`, and probably any other redirect response code) and `redirect` is set to `follow`, the second request is made _without_ an `Authorization` header, which breaks our website. In 110.0 this isn't an issue, and no warning is logged to tell us it's about to change. I'm guessing this is a security change - could someone point me at the discussion that led to it being made? My feeling is that if the redirect is to the same origin as the original request sending the same `Authorization` header should be secure enough. I'm wondering what the right mitigation is; we could follow redirects manually of course, but it's a pain.

Chosen solution

whatwg/fetch#1544 changes the Fetch Standard to remove a web-developer-set Authorization header upon a cross-origin redirect.

According to https://wpt.fyi/results/fetch/api/credentials/authentication-redirection.any.html, WebKit (Safari 16.3 preview) and Gecko already conforms with this spec change — but Chromium do not yet.

Read this answer in context 👍 0

All Replies (8)

more options

I think that we don't have any info about it off-hand. Are you able to narrow it with mozregression? It would be the easiest procedure.

more options

Thanks, neat tool. My issue was caused by the fix to this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1802086 ; the commit was c1a19f563004c0a3b5d849976c35e3630ae71ede

I've raised https://bugzilla.mozilla.org/show_bug.cgi?id=1817980

Modified by rob204

more options

That was fast :).

It looks like it was due to specification change. We follow every other browser, it's a standardized behavior.

But I can see in a code, that we're using network.fetch.redirect.stripAuthHeader pref. Perhaps it's enough for you to switch it to false.

more options

I can't ask all our users to change their firefox preferences.

It's not current behaviour on Chrome latest Version 110.0.5481.100 (Official Build) (arm64)

It's not current behaviour on Safari latest Version 16.2 (18614.3.7.1.5)

more options

For some reason my original response has disappeared...

mozregression is a cool tool, like that - made it very easy to track down.

My issue is caused by commit c1a19f563004c0a3b5d849976c35e3630ae71ede

Commit message: Bug 1802086 - remove auth header from redirected cross-origin requests. r=necko-reviewers,smaug,valentin

The change also updates WPT based on the discussions here https://github.com/web-platform-tests/wpt/pull/37145/files#r1042166622

The bug it references: https://bugzilla.mozilla.org/show_bug.cgi?id=1802086

I've raised https://bugzilla.mozilla.org/show_bug.cgi?id=1817980 explaining my perspective.

more options

Chosen Solution

whatwg/fetch#1544 changes the Fetch Standard to remove a web-developer-set Authorization header upon a cross-origin redirect.

According to https://wpt.fyi/results/fetch/api/credentials/authentication-redirection.any.html, WebKit (Safari 16.3 preview) and Gecko already conforms with this spec change — but Chromium do not yet.

more options

I would argue it isn't cross origin. It's a different origin to the current webpage, but I don't see why that's an issue.

fetch("https://firefox-redirect-issue.wiremockapi.cloud/redirect", {

 "headers": {
   "Authorization": "Token foo"
 }

});

gets a 302 with Location: https://firefox-redirect-issue.wiremockapi.cloud/authorized

which is the same origin (https://firefox-redirect-issue.wiremockapi.cloud) as the original request.

more options

OK. Let's see what devs say. You can close this support question now.