搜尋 Mozilla 技術支援網站

防止技術支援詐騙。我們絕對不會要求您撥打電話或發送簡訊,或是提供個人資訊。請用「回報濫用」功能回報可疑的行為。

了解更多

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

  • 8 回覆
  • 0 有這個問題
  • 1 次檢視
  • 最近回覆由 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.

被選擇的解決方法

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.

從原來的回覆中察看解決方案 👍 0

所有回覆 (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

由 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

選擇的解決方法

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.