whatwg/url

Consider introducing a "same-site" concept that includes scheme.

mikewest opened this issue ยท 7 comments

As discussed in w3c/webappsec-fetch-metadata#34, we're slowly tightening the various places that evaluate URLs'/Origins' same-siteness to look beyond the host and require scheme matches as well.

That is, http://example.com/ and https://sub.example.com/ have hosts which are considered
"same-site", but many places in the platform have begun considering those contexts "cross-site" as the non-secure scheme creates risk for the secure origin.

To quote from that other thread:

@mikewest
In fact, I wonder if we can/should change this more generally for URL's "same site" definition, as it's something we run into in ~all the "same-site" checks we're introducing these days.

In fact, SameSite cookies might be the only place where we're not doing this kind of check. We made that decision because we wanted people to be able to upgrade their sites to HTTPS piecemeal, starting with their authentication systems, then spreading throughout the site. Perhaps we've reached enough of an inflection point with that migration that we can tighten the restriction generally.

@annevk
I'm supportive. We could have schemeless same site or some such for the variant that only takes hosts. https://fetch.spec.whatwg.org/#cross-origin-resource-policy-check also needs schemeless btw, even though it ends up checking the scheme a bit.

I guess to be useful we should define this for both origins and URLs.

I agree. The latter seems reasonably placed in URL. Would you prefer the former to live in HTML?

Oh that's a good question, I guess so? And have the latter defined in terms of the former? It'll all be rather circular though, hope that's acceptable to people (I guess in practice almost nobody will click through to verify things make sense).

Indeed.

(Note that I haven't asked what RFC6265bis needs to depend on for SameSite (or whether HTML/URL should depend on it?), because that will be an exciting conversation that @mnot should probably be involved in.)

I'll try to send you PRs that we can chat about at TPAC.

(@annevk: Would you be willing to allow me to upload branches to this repository? It would save me the trouble of forking it again (which, admittedly, isn't much trouble. :)).

You should have write access now.