Proposal: `Sec-Site` should capture information about the requester of a resource

[arturjanc]

This is a follow-up to #687, specifically: #687 (comment)

Background

To protect against cross-origin information leaks, exploitable by embedding a victim application's resources in an attacker-controlled document and inferring information about their contents, it would be useful to have a universal way to provide the application with information about the sender of the request with a request header. This would enable server-side decisions about whether to respond with sensitive resources depending on the context in which they are embedded, and could provide a robust way to protect against attacks such as CSRF, XS-Search, cross-origin timings and Spectre-like bugs.

This is conceptually similar to the Origin header, but would need to be present on all resource requests (possibly only to origins which opt in) -- otherwise an attacker could embed the resource in a way which doesn't cause the header to be sent, without giving the server the opportunity to reject the request. Servers which want to add protection against cross-origin information leaks would inspect the value of the Sec-Site header and could reject requests from origins they do not trust.

Details

From an adopter's point of view, the most useful variant would be identifying the source of the request with its origin, e.g.

Sec-Site: foo.example.org

In #687 (comment) @annevk mentioned some sensible concerns about sending the full origin value that I hope he can elaborate on here :) I expect that we can (and should!) make this feature fully compatible with the Referrer Policy by doing the following:

• If the request includes a Referer header that contains the origin, send the exact origin value.
• If the request wouldn't otherwise have any identifying information about its origin, send one of same-origin, same-site or cross-site (spelling TBD).

This way most developers could write code such as:

if not request.headers.get("Sec-Site") in ["foo.example.org", "same-site"]: # reject

In applications which don't have a Referrer Policy of no-referrer this would be even simpler because the developer could just rely on a URL whitelist.

I'd be a little wary of going with just the coarse-grained values because many applications have resources which are legitimately requested cross-origin, which wouldn't allow the developer to protect them. WDYT @annevk, would that be reasonable?

Questions

This is obviously just a sketch of the idea; if we want to pursue it more, we should probably think about the following issues:

• Should it be a per-origin opt-in (via Origin Policy) or enabled by default?
• Does it need a new header, or is there a benefit to overloading Origin instead (FWIW my guess is that would be ugly.)
• Can we include some more metadata about the request, for example:
  • Whether this request is a navigation, rather than a subresource load.
  • The type of the resource that the request is going to be used as, e.g. "image" vs. "script"
• Naming: particularly if we add metadata, the header would no longer just identify the requesting site so we might need to rephrase it.

@mikewest certainly has some thoughts about this as well.

[annevk]

Making it compatible with Referrer Policy could work, but I think that would disadvantage UAs who want a non-default policy there. E.g., if in the future they decide they should reveal less, it's highly likely they'd break sites that come to rely on this header returning a certain value.

[arturjanc]

That's a good point; though I think this would only happen if a UA adopted a default RP of no-referrer, which would likely break other existing things (any other default RP should be okay here).

The way to tackle it probably depends on whether we think it would be the responsibility of the UA or site authors to prevent applications using Sec-Site from breaking:

• If we think the no-referrer default is the right model in the long term, we could ask developers with resources loaded cross-origin to configure requesting origins with Referrer-Policy: strict-origin or directly add the referrerpolicy attribute to any authenticated resource requests in JS libraries. Then, whenever UAs stop sending the Referrer, it would be a no-op for applications which use Sec-Site and have a custom RP.
• If the no-referrer default is more of an optional feature that will not be broadly deployed by UAs -- and hence we can't get developers to make their sites compatible with it -- we could prevent breakage by having the UA not send the Sec-Site header in such cases. For example, in a hypothetical private browsing mode which removes the Referrer completely, the UA could perhaps opt out of the security protections of Sec-Site under the (somewhat optimistic) assumption that users are less likely to have long-lived authenticated sessions which benefit from cross-site infoleak protections.

I don't really like the explicit security vs. privacy tradeoff of the second option, but depending on how we see the Referrer-disabling mode being used, maybe it could be worth considering.

[mikewest]

I think this is a good direction to explore, allowing a developer to make granular decisions about ACLs for particular resources/requests based on its initiator. I think I agree with the advantages @arturjanc posits, and I also agree with his analysis of the Referrer Policy integration. I'd go further than @arturjanc, actually, and suggest that same-origin/same-site/cross-site is coarse-enough that we'd be able to justify sending it even in the presence of no-referrer, which would mitigate the risk of "breaking" sites that relied on a requester revealing something about itself in order to service a given request.

Before diving too deeply into details (and I'd add redirect behavior to the list of @arturjanc's questions), I'd be curious about the rest of @whatwg/security's opinion on the proposal more generally. It seems pretty reasonable to me, and worth the time to sketch out.

[annevk]

@mikewest I think it would only mitigate the risk if those were the only values transmitted.

[mikewest]

I think it would only mitigate the risk if those were the only values transmitted.

Well, let's start with that as a baseline: could we agree that sending the three-value enum would be fine?

I believe there's some real value in more granularity above and beyond that enum for services that wish to expose data to some subset of cross-origin entities, but not all cross-origin entities (for example: mail.google.com might trust accounts.google.com, but not docs.google.com; google.de might trust accounts.google.com, but not evil.com) Neither same-site nor cross-site would be granular enough to create those ACLs).

Perhaps we could send both? That is, we might send Sec-Site: same-site, https://docs.google.com and Sec-Site: cross-site, https://evil.com? Developers could be encouraged to check the low-granularity bit that they know will always be present, and look to the origin when included to increase the check's robustness?

(As an aside: is this a practical concern, or a theoretical concern? That is, is Mozilla pondering killing referer (or revisiting @briansmith's https://briansmith.org/referrer-01)? That would be interesting!)

[annevk]

Theoretical at this point, but it seems good to allow for it. Exposing both bits (perhaps space-separated to make it different from multiple headers) seems like an interesting approach. That at least doesn't result in unexpected values on the server side. A cross-origin redirect or sandbox would make the second bit null.

[mikewest]

Including both values (separated by whatever characters you like!) seems valuable, independent of the referrer policy concerns, as same-origin, etc. is likely to be simpler for developers running in development environments to deal with. Simpler than hard-coding both development server names and prod server names, in any event.

[johnwilander]

I believe there's some real value in more granularity above and beyond that enum for services that wish to expose data to some subset of cross-origin entities, but not all cross-origin entities (for example: mail.google.com might trust accounts.google.com, but not docs.google.com; google.de might trust accounts.google.com, but not evil.com) Neither same-site nor cross-site would be granular enough to create those ACLs).

I thought we agreed that same-site would mean same eTLD+1 for these purposes. Not true? I pointed this out regarding SameSite cookies in #687 (comment) but then the thread seemed to go on to say that same-site should be same eTLD+1.

[johnwilander]

Should it be a per-origin opt-in (via Origin Policy) or enabled by default?

It looks like Origin Policy is stateful cross-site. True? From the spec:
"The Sec-Origin-Policy HTTP request header field is sent with navigational HTTP requests in order to advertise support generally for the origin policy manifest mechanism defined in this document, and to inform the server which version of its origin policy is cached locally."

If so, it won't fly for us for anti tracking reasons. Maybe partitioning would make sense. Were there any thoughts on that?

[annevk]

@johnwilander same-site does mean eTLD+1, but cross-origin != cross-site. What @mikewest was trying to demonstrate is that sometimes having the actual origin is useful to make decisions, even if it's same-site or cross-site. As for Origin Policy, I think folks had thoughts on removing the statefullness somehow, but no progress has been made recently. The draft as it stands today is known not to work for Safari.

[johnwilander]

@johnwilander same-site does mean eTLD+1, but cross-origin != cross-site. What @mikewest was trying to demonstrate is that sometimes having the actual origin is useful to make decisions, even if it's same-site or cross-site.

Ah, got it. I misread his comment. He does imply that same-site is eTLD+1.

As for Origin Policy, I think folks had thoughts on removing the statefullness somehow, but no progress has been made recently. The draft as it stands today is known not to work for Safari.

OK. Thx.

[arturjanc]

It's not hugely important, but if we can make it work without gating on Origin Policy I would also prefer that. I mentioned this possibility because an origin-level opt-in would address past concerns about request size (#687 (comment)), but it would be easier for developers if we could send this information by default.

[dveditz]

Is there any room in this proposal for including the type of request (corresponding to the "AS script" etc in other specs). If you've got a document URL with params and it's being requested as an IMG then it's probably an attack of some kind.