search

w3c / webappsec-fetch-metadata

Fetch Metadata
https://w3c.github.io/webappsec-fetch-metadata/
Other
76 stars 28 forks source link

`Sec-Fetch-Ancestors`? #56

Open mikewest opened 4 years ago

mikewest commented 4 years ago

@davidben pointed out that we made a decision in Fetch Metadata to send the site-relationship between the initiator and the target in Sec-Fetch-Site, which doesn't allow servers to make the same decisions as we make with SameSite cookies, which send the relationship between the initiator and all its ancestors and the target. Perhaps we should add another header containing this relationship, which would allow servers to unifiy the declarative logic of SameSite with server-side logic around other characteristics of a request?

/cc @arturjanc @lweichselbaum @ckerschb WDYT?

mikewest commented 4 years ago

That is, A nested in A would send the following when making a request to A: Sec-Fetch-Site: same-origin and Sec-Fetch-Ancestors: same-origin. A nested in B would send the following when making a request to A: Sec-Fetch-Site: same-origin and Sec-Fetch-Ancestors: cross-site.

mikewest commented 4 years ago

(Note that this is somewhat similar to @deian, et al's Sec-Frame-Same-Origin proposal, but with some details shifted: it would be an enum value, like Sec-Fetch-Site, and it would be sent for every request, specifically including subresources, which seems necessary for servers to replicate the behavior of SameSite cookies)

annevk commented 4 years ago

Precedent in naming: X-Frame-Options, frame-ancestors, ancestorOrigins (disputed and not shipped in Firefox), window.frameElement, window.parent, window.top.

I would expect Frame in the name here.

mikewest commented 4 years ago

Sure: Sec-Fetch-Frame-Ancestors: whatever to match CSP?

deian commented 4 years ago

I'd love to see this!

arturjanc commented 4 years ago

Sounds reasonable to me as well. I like the consistency with Sec-Fetch-Site and also the fact that this would allow developers to better test upgrading their cookies to SameSite.

@mikewest For a top-level navigation, would it make sense to set Sec-Fetch-Frame-Ancestors: none? This could map to the strict vs. lax distinction, i.e.:

I haven't really thought this through, and perhaps we're already getting most of this information from Sec-Fetch-Site: none, but site=none could also be sent by some non-webby non-top-level requests, so having this value in Sec-Fetch-Frame-Ancestors seems potentially useful.

mikewest commented 4 years ago

Hrm. I started typing something else, but this might actually be a reasonable proposal... It would match CSP's semantic of frame-ancestors 'none', which is a nice property. I know we can't trivially implement it this way in Chrome, but it wouldn't be too terrible, I think.

lweichselbaum commented 4 years ago

+1 I like the idea and how well it fits into existing semantics of CSP and SameSite cookies.

mikewest commented 6 months ago

I started poking at this again between meetings over the last few weeks. I still think it's a reasonable thing to add to the platform, and it seems to be more interesting to more developers these days given the partitioning story for storage, etc.

I took a stab at one formulation of details in https://github.com/w3c/webappsec-fetch-metadata/pull/89. I'd appreciate thoughts there about how we should handle various cases (top-level navigations stand out, but there are likely other interesting edges to test).