1768185 - Origin header should NOT honor ReferrerPolicy no-referrer for CORS requests

Status: RESOLVED FIXED

(Core :: DOM: Security, task, P3)

Description

[Tom Schuster (MoCo)]

Bug 1504085 added code to honor the Referrer-Policy and set the Origin header to null when appropriate. However this is explicitly not done when dealing with CORS requests.

  // When we're dealing with CORS (mode is "cors"), we shouldn't take the
  // Referrer-Policy into account

https://searchfox.org/mozilla-central/rev/408eac3ccaea2d35b00706925d4d944803e19aba/dom/security/ReferrerInfo.cpp#422

When testing Bug 1605305 I still got failures on the fetch/origin/assorted.window.html test for

Origin header and POST same-origin fetch cors mode with Referrer-Policy no-referrer

Comment 1

[Daniel Veditz [:dveditz]]

This is a philosophical dilema.

• If Origin: doesn't honor no-referrer then a site leaks its origin in CORS connections
  • however, the site itself chose the no-referrer policy, and clearly wants CORS to work
  • if the site is hacked, it could reveal the user was there through other ways, like GET url parameters
• If we do honor the no-referrer policy for Origin: then nearly all CORS requests will fail
  • that failure might tempt a site to allow Origin: null credentialed CORS requests, which then exposes their user data to any site that wants it

This was argued, and the intersection of Referrer Policy and CORS is specified in the Fetch spec. The spec notes "A request’s referrer policy is taken into account for all fetches where the fetcher did not explicitly opt into sharing their origin with the server, e.g., via using the CORS protocol. " -- that is, the site itself is in control of both the referrer policy and the use of CORS requests.

The spec does not take into account that some highly configurable and privacy conscious browsers (i.e. Firefox) have ways to let users choose their own Referrer Policy and impose that on sites, and therefore the site itself might not be balancing the use of CORS and no-referrer. Configuration is great, but that doesn't change the fact that imposing a Referrer Policy on CORS is going to break functionality and is unlikely to be what users want. If we must have a way to neuter Origin in all cases it should be a separate setting. Let the user's referrer policy override referrer policy, but let it work like referrer policy in all the specified ways including deferring to CORS and WebSocket use of the Origin: header. If it's really desired, set up a separate "break CORS" pref to set Origin to null.

As currently summarized ("Origin header should honor ReferrerPolicy no-referrer even with CORS") this is INVALID/WONTFIX because it directly contradicts the specs. Browser compatibility is important, and if this change is also important it needs to be argued to get this changed in the Fetch spec.

Comment 2

[Tom Schuster (MoCo)]

I have to admit I wasn't really aware of any of these problems before opening the issue and just wanted to have the test failure documented.
Doesn't Step 2. of the spec you linked to always append the Origin for cors requests even before looking at the referrer policy?
I also don't think having the Origin for same-origin CORS request is that problematic from a privacy perspective.

Comment 3

[Daniel Veditz [:dveditz]]

Doesn't Step 2. of the spec you linked to always append the Origin for cors requests even before looking at the referrer policy?

Yes, and Step 3 starts "Otherwise", meaning it only looks at the referrer policy (wrt the Origin header) for non-cors requests. Those include the cases bug 1605305 is complaining about.

Comment 4

[Tom Schuster (MoCo)]

But this bug is about this test failure "Origin header and POST same-origin fetch cors mode with Referrer-Policy no-referrer" that seems to indicate it's a same origin CORS request that has a missing Origin header, as required by Step 2.

Comment 5

[Daniel Veditz [:dveditz]]

Yes, bug 1605305 is largely about us not sending Origin: at all (should be null) in some cases. This bug sounded like you wanted to change some cases where we do send Origin: https://example.org to Origin: null and I believe that is wrong or mostly wrong (CORS origin headers also get changed to null when going through multiple origin redirects).

I suppose my main confusion is how is this bug different from bug 1605305?

Comment 6

[Tom Schuster (MoCo)]

I think there is no strong relation to bug 1605305, it's just the last remaining failure after fixing all other test cases.

I am actually starting to think that either the spec or the test might be faulty. No other browser seems to sending the real origin and instead sends null. https://wpt.fyi/results/fetch/origin/assorted.window.html?label=master&label=experimental

Comment 7

[Tom Schuster (MoCo)]

So coming back to this: Firefox is now the only browser that passes this test. In fact we pass all fetch/origin/assorted.window.html tests now. When I initially reported this bug I was still using an older version of my patch in bug 1605305. Turns out that I wasn't implementing

2. If request’s response tainting is "cors"

correctly before, which was causing this test failure. It seems like all other browsers have a similar issue, but I would say the spec actually makes sense.

Comment 8

[Tom Schuster (MoCo)]

Apparently this is a known spec issue that we have run into before with bug 1632204. This is causing issues again with bug 1775235. There is apparently already an issue on the fetch github as well: https://github.com/whatwg/fetch/issues/1022

Comment 9

[Tom Schuster (MoCo)]

My spec PR was accepted, we can now update our implementation with the new steps. With the next mozilla-central WPT update we should also be able to remove the expected-fail: https://github.com/web-platform-tests/wpt/pull/36332.

Comment 10

[Tom Schuster (MoCo)]

Attachment: Bug 1768185 - Update spec steps for CORS fetch Origin. r?#necko-reviewers

Our existing behavior was specified in https://github.com/whatwg/fetch/pull/1463.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/091575695f60
Update spec steps for CORS fetch Origin. r=necko-reviewers,dragana,freddyb

Comment 12

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/091575695f60