Bug 260284

Summary:	Incorrect Sec-Fetch-Site values on sandboxed iframes
Product:	WebKit	Reporter:	Jerry Zhang <jerryzz>
Component:	Frames	Assignee:	youenn fablet <youennf>
Status:	RESOLVED FIXED
Severity:	Normal	CC:	achristensen, annevk, bfulgham, cdumez, jerryzz, pgriffis, vincentlee, webkit-bug-importer, wilander, youennf
Priority:	P2	Keywords:	InRadar
Version:	Safari 16
Hardware:	Unspecified
OS:	Unspecified
See Also:	https://bugs.webkit.org/show_bug.cgi?id=256472

Description Jerry Zhang 2023-08-16 13:06:27 PDT

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.

Comment 1 Radar WebKit Bug Importer 2023-08-23 13:07:16 PDT

<rdar://problem/114340186>

Comment 2 Vincent Lee 2024-05-31 10:20:24 PDT

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

Comment 3 Vincent Lee 2024-05-31 10:31:35 PDT

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.

Comment 4 youenn fablet 2024-06-03 01:23:05 PDT

I think Chrome and FF are correct here. The env origin is the top level frame.

Comment 5 youenn fablet 2024-06-03 02:31:11 PDT

Pull request: https://github.com/WebKit/WebKit/pull/29450

Comment 6 EWS 2024-06-16 23:37:57 PDT

Committed 280065@main (deeefb52b7fd): <https://commits.webkit.org/280065@main>

Reviewed commits have been landed. Closing PR #29450 and removing active labels.