Sec-Fetch-Site utility for resources that need to be exposed cross-site

[anforowicz]

When discussing Cross-Origin Resource Policy v1, @arturjanc mentioned that

The problem with not allowing granular control in From-Origin is that it will be impossible for developers whose resources are loaded cross-site to use the header, even if they fully control the requesting domain.

Doesn't the same problem apply to Sec-Fetch-Site? As currently proposed the header values are limited to "cross-site", "same-origin", and "same-site" - when seeing a "cross-site" value the server won't be able to distinguish between https://friendly.origin.at.another.site.com VS https://attacker.com, right?

[mikewest]

IMO, it does. We initially proposed sending the actual origin, and got a reasonable amount of pushback (see the conversation ending in whatwg/fetch#700 (comment)). I'd still like to send the origin, but sending this enum has some value in itself, and seems like the right place to start, given the way the conversation evolved.

[arturjanc]

What @mikewest said :)

One reason why I'm okay living without this information in Sec-Fetch-Site (whereas I see it as a larger obstacle for CORP) is that the server will get reliable data about which of its resources are being requested cross-site and it can exempt them from enforcement. The premise here is that many applications have some endpoints that are legitimately being loaded as cross-site subresources, but that it's a small subset. Instead of addressing this by building a list of trusted cross-site origins that can request resources, developers should be able to opt out some of their endpoints, but could still enforce restrictions on the rest of their application.

With CORP, a server that sets the header doesn't have information that allows it to determine which endpoints are loaded cross-origin and build the list of endpoints to opt out -- which makes it quite difficult to avoid accidentally breaking some legitimate loading scenarios.

Note that all of this applies only to no-cors mode because for cors loads the Origin header already carries this information. For the specific case you're outlining (no-cors cross-site loads of sensitive resources where the server would like to restrict the origins of the requesters) one final, somewhat unsatisfactory, escape hatch is using the Referrer to allow access by trusted cross-site requesters. This could potentially also work for CORP, but the problem there is that disallowing requests without a Referer (which is necessary to make this safe) would break users with Referer-stripping extensions; with Sec-Fetch-* this could be limited only to cross-site scenarios, which might make this more deployable. Still, as this gets complex, my guess is that the base case would be applying the restrictions to those resources which aren't being loaded cross-site, which is fairly simple with Sec-Fetch-*.

[anforowicz]

Thanks for the explanations! I am fine with closing this issue as WontFix - just wanted to check that this aspect of the design has been taken into account and won't impact adoption too much.

[arturjanc]

Yeah, I'd definitely prefer to have origin information available for making security decisions, but I expect that its lack won't be a dealbreaker in this context, even if it makes deployments harder.

Still, there are some interesting complementary ideas such as sending the Origin header with every request (like we already do for CORS), which we might want to dust off at some point ;-)