The Sec-Fetch-Site header is supposed to reflect the relationship between the origin of request's initiator and the origin of it's target. (https://w3c.github.io/webappsec-fetch-metadata/#sec-fetch-site-header) However, the current behavior seems to be incorrect for sandboxed iframes where a same-origin url will result in a Sec-Fetch-Site header with value "cross-site". i.e. Reproduction steps: Visit https://polar-purrfect-pangolin.glitch.me/sandboxediframe.html which contains: <iframe src="https://polar-purrfect-pangolin.glitch.me/" sandbox></iframe> Expected behavior: The Sec-Fetch-Site header of the sandboxed iframe request has value "same-origin" Actual behavior: The Sec-Fetch-Site header of the sandboxed iframe request has value "cross-site" https://bugs.webkit.org/show_bug.cgi?id=256472 may be related.
<rdar://problem/114340186>
Hi, what's the status on this? We'd love to roll out serverside security checks for Safari based on the Sec-Fetch headers, but Sec-Fetch-Site not being correct is giving us pause. We've rolled out on all other browsers, so only Safari is left. This appears to still be a bug in Safari 17.5
Actually, on further reading of the spec, I'm Chrome and FF might be the ones with the bug here. Sandboxing an iframe without `allow-same-origin` means the origin becomes opaque, and if I'm reading the language correctly for Sec-Fetch-Site, the algorithm for setting the header asserts that the request is from a "potentially trustworthy origin", which an opaque origin is not.
I think Chrome and FF are correct here. The env origin is the top level frame.
Pull request: https://github.com/WebKit/WebKit/pull/29450
Committed 280065@main (deeefb52b7fd): <https://commits.webkit.org/280065@main> Reviewed commits have been landed. Closing PR #29450 and removing active labels.