When following cross-origin redirect, Firefox sends preflight request with "Access-Control-Request-Headers: authorization" even though "Authorization" header will never be forwarded.
Categories
(Core :: Networking: HTTP, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox126 | --- | fixed |
People
(Reporter: ae.nesterov, Assigned: smayya)
References
(Blocks 1 open bug)
Details
(Whiteboard: [necko-triaged][necko-priority-queue], [wptsync upstream])
Attachments
(4 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:121.0) Gecko/20100101 Firefox/121.0
Steps to reproduce:
Given a client and a server (A) on the same origin and a server (B) on a different origin.
- The client sends GET request with "Authorization" header to the server (A).
- The server (A) responds with status code 3xx and "Location" header (i.e. redirect to a resource on the server (B)).
Note that on cross-origin redirect, Firefox remove "Authorization" header:
https://bugzilla.mozilla.org/show_bug.cgi?id=1802086
Actual results:
- Firefox sends preflight (i.e method=OPTIONS) request to the server (B) with "Access-Control-Request-Headers" header set to "authorization".
- Firefox sends the actual request (i.e. method=GET) to the server (B) without "Authorization" header.
Expected results:
- Firefox sends preflight (i.e method=OPTIONS) request to the server (B) without "Access-Control-Request-Headers" header set to "authorization", because the "Authorization" header will never be forwarded (base case: if simple, the request is not send at all).
- Firefox sends the actual request (i.e. method=GET) to the server (B) without "Authorization" header.
Comment 1•8 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Networking: HTTP' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 2•8 months ago
|
||
Thank you for this report.
This seems entirely valid, but out of curiosity, have you tested what other browsers are doing?
This test case seems like it should been included in WPT for XHR and fetch - so that we have consistent behaviour.
Reporter | ||
Comment 3•8 months ago
|
||
Hi Valentin,
For our use case with a simple request, both Chrome 120.0.6099.216 and Safari 17.2.1 neither send preflight request nor forward "Authorization" header to the server (B).
I have a similar steps with a related bug (inconsistent origin) and I have same issue with authorization header.
Firefox 121.
Open https://example.com
In the dev console execute fetch('https://echoserver.dev/server?response=N4IgFgpghgJhBOBnEAuA2mkAZA9gYygBcBLHAOxABpxDCAHRFAeibFroCNiyA6HeAOatocJCAC6lTFDx4IiRAFo85QvBwAbRVA0acAd0X9iA7lRAAqCZJAccMAJ6pQhB3QioQhCAA9C5mCIoTxAAX2pEQiIAV2QUAGYABgAmahUkAAV4CAAzDRM2Z3ARBDiMEBk5BWVVdS0dPUNjUwpqK0lpWXklFTI1TW1dA0VIWFLzKGjCMGMALyJSMkofRUIcAGsICnEbSJi45MSAFlDQoA',{headers: {authorization: "TOP-SECRET", "x-token":"SECRET"}}).then(async response=>console.log(await response.json()), console.error)
It will send request with authorization header to echoserver.dev, after redirect (302), it will send preflight request to httpbin.org with Origin https://example.com
but the final request has Origin null
Comment 7•8 months ago
|
||
Thank you for the report. This seems like a valid issue. I hope Sunil can take a look soon.
Assignee | ||
Updated•8 months ago
|
Assignee | ||
Updated•7 months ago
|
Assignee | ||
Comment 8•6 months ago
|
||
Pushed by smayya@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/9b7d17339ad8 remove auth headers from preflight request for cross origin requests. r=necko-reviewers,valentin
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/45156 for changes under testing/web-platform/tests
Comment 11•6 months ago
|
||
bugherder |
Upstream PR merged by moz-wptsync-bot
Description
•