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•2 years 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•2 years 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•2 years 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).
| Reporter | ||
Comment 4•2 years ago
|
||
Example of the redirect in Chrome.
| Reporter | ||
Comment 5•2 years ago
|
||
Example of the redirect in Safari.
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•2 years ago
|
||
Thank you for the report. This seems like a valid issue. I hope Sunil can take a look soon.
| Assignee | ||
Updated•2 years ago
|
| Assignee | ||
Updated•2 years ago
|
| Assignee | ||
Comment 8•1 year ago
|
||
Comment 11•1 year ago
|
||
| bugherder | ||
Description
•