Referrer policy of "no-referrer" sets Origin to null on same-origin "cors" requests

[annevk]

In particular, for requests whose method is neither GET nor HEAD due to step 3 of https://fetch.spec.whatwg.org/#append-a-request-origin-header. This is not web-compatible as per https://bugzilla.mozilla.org/show_bug.cgi?id=1632204.

This means we need to revisit https://github.com/web-platform-tests/wpt/pull/22567 and this algorithm yet again.

Given that we have to reveal the origin, the simplest would be to always include it for "cors" requests, including when they are same-origin. I.e., change the check for response tainting is "cors" to mode is "cors". (This might well be how things behaved in the past.)

cc @rwlbuis @yutakahirano @JuniorHsu

[evilpie]

I just ran unwittingly into this problem again after closely trying to implement the spec. It would be nice to at least warn in the spec that the current definition isn't web-compatible.

https://bugzilla.mozilla.org/show_bug.cgi?id=1775235 https://bugzilla.mozilla.org/show_bug.cgi?id=1768185

[evilpie]

The current implementation in Gecko could be specified roughly like this:

2. If request’s response tainting is "cors" or request’s mode is "websocket", then append (Origin, serializedOrigin) to request’s header list. (unchanged)
3. Otherwise, if request’s method is neither GET nor HEAD, then: 3.1 If request’s mode is "cors", then append (Origin, serializedOrigin) to request’s header list. 3.2 Otherwise, Switch on request’s referrer policy: [....] 3.3 Append (Origin, serializedOrigin) to request’s header list.

So basically we always add the real Origin to CORS requests that aren't using the GET or HEAD request method.

[dlongley]

Given that we have to reveal the origin, the simplest would be to always include it for "cors" requests...

Shouldn't there be some way of sending a request (at least a non-same-origin request, including non-HEAD/GET methods) without an origin header, without making the response opaque, and without sending any credentials, in order to enable more privacy-preserving web applications? If the target server allows any origin (Access-Control-Allow-Origin: *) is there still a security danger in that case?

My understanding is that web apps have to implement HTTP proxies in these cases in order to get to parity with native apps.