Firefox not sending original Authorization header when fetch follows a redirect in 112.0
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 👍 0All Replies (8)
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.
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
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.
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)
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.
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.
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.
OK. Let's see what devs say. You can close this support question now.