Re: [whatwg/fetch] Proposal: `Sec-Site` should capture information about the requester of a resource (#700)

Yesterday at WebAppSec we had a chance to briefly talk about the aspect of this proposal which would expose the actual origin of the sender of a resource request, as opposed to a more coarse-grained value (`same-site`, etc). I'll attempt to summarize @TanviHacks's concerns here because it's a sticking point that's worth discussing; if we can't agree, I think we may just want to go with the coarse-grained values for now. But I hope we can agree! :)

The main concern is that we'd be building a "new Referrer" which would reveal the originator of the request, but in a new place. Given that the `Referer` header often carries sensitive information, there is an ecosystem of tools and features that attempt to protect users from Referrer leakage. For example, Firefox has [fine-grained Referrer configuration options](https://wiki.mozilla.org/Security/Referrer) and there are [extensions](https://chrome.google.com/webstore/detail/referer-control/hnkcfpcejkafcihlgbojoidoihckciin?hl=en) which strip the header. If we now expose similar information elsewhere, then such tools would either be less effective or they will have to be modified to also handle the new header -- in which case they might strip the origin information from `Sec-Site` similarly to how they remove the `Referer`, so sites that rely on this value to allow cross-origin requests from trusted origins would break. @TanviHacks, is this a reasonable summary?

(Narrowly, on the last point about possible site breakage: I think we could handle this case by making sure to remove the entire `Sec-Site` header instead of just stripping the origin value, in which case the server would respond to the request as usual, as outlined in https://github.com/whatwg/fetch/issues/700#issuecomment-381392289)

When it comes to the general worry about disclosing the requester's origin in `Sec-Site`, I think this may be qualitatively different from the issues we have with `Referer` leakage, for a non-obvious reason. Basically, `Referer` is sent on both _navigations_ and _resource requests_; I expect the bulk of the privacy concerns are related to leaking its value on cross-origin navigations, rather than when fetching resources, which is the case that `Sec-Site` focuses on. My guess is that preventing disclosing information about the document origin _on resource requests_, which we care about here, is not the primary motivation of existing `Referer` protections. 

The main reason I think so is that for cross-origin requests in `"cors"` mode we're *already* exposing the requesting origin to allow the server to make authorization decisions -- AFAIK the `Origin` header isn't stripped by most `Referer` protections and their users would not consider this to be a failing of such tools. Another thing to keep in mind is that in many cases resources are implicitly trusted by applications that load them and usually get much more power than being able to know the requesting origin, e.g. scripts and stylesheets get almost free rein over the DOM. There are certainly cases where developers don't fully trust the resources they embed and do not want to disclose their origin on such requests, but they can do so via Referrer Policy, which `Sec-Site` would respect.

So, from the application developer's point of view, `Sec-Site` would not send any more information than what is currently present in resource requests. From the point of view of a privacy-conscious user of Referrer-stripping software, the type of information included in `Sec-Site` (i.e. the origin) is already present in CORS requests and is fairly coarse-grained. From the point of view of a developer of privacy tools (e.g. the hypothetical Referer-less private browsing mode), any potential site breakage can be avoided by removing the header completely, since servers will have to accept all requests without it for compatibility with older browsers.

If, despite the things mentioned above, exposing the requesting origin in `Sec-Site` is still a concern, perhaps it may be workable (though harder for developers) to do it on an opt-in basis. For example:
- We could send it only on requests originating from pages which set a Referrer Policy, treating it as an explicit signal that the developer has thought about what is appropriate to expose in the `Referer` (and if the RP is `no-referrer`, omit the origin). Developers with resources requested across origins would first add RP to make sure that their cross-origin requests all come from cooperating sites.
- We could build a completely separate switch which developers would use to the same effect as above. It could be more configurable, e.g. it could only send the origin if the destination matches a whitelist, but it would likely be substantially more work to implement and adopt.

The reason I'm pushing on this aspect (sorry for being a pest!) is that having reliable origin information in resource requests, particularly by default, would make it *much* easier to deploy protections from cross-origin leaks in any application that isn't fully self-contained in a single origin, or has endpoints that may legitimately be requested cross-origin. The application could first gather origin information from existing requests, build a whitelist of origins which currently load data from it, and then lock down processing of sensitive responses to requests from the whitelisted origins. If a significant number of requests only carried the `cross-origin` designation without any identifying information, it would be difficult for developers of this class of applications to enforce meaningful restrictions on cross-origin resource loads, which is the main impetus behind this change, and one of the more promising approaches to tackle Spectre and other information leaks.


 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/700#issuecomment-382762249