Bug 230350

Created attachment 438351 [details] Safari accetps cookie loaded via 3rd-party frame, see https://github.com/jaylinski/safari-same-site-cookie for more screenshots ## Description of the issue Safari doesn't send "SameSite=Lax" and "SameSite=Strict" cookies to a same-site if the same-site was loaded by a cross-site iframe (Which is the correct behavior.) But: Safari *accepts* "SameSite=Lax" and "SameSite=Strict" cookies from a same-site if the same-site was loaded by a cross-site iframe. (Which is probably the wrong behavior.) The behavior from Safari differs from the behavior of Chrome and Firefox. Both Chrome and Firefox block "SameSite=Lax" and "SameSite=Strict" cookies if they came by a same-site loaded by a cross-site iframe. ### Example |- a.tld |-- [iframe] b.tld |--- [iframe] a.tld (Set-Cookie: x=y; path=/; SameSite=Lax) Safari will accept the `x`-cookie, while Chrome and Firefox reject it, because "it came from a cross-site response". ## Expected behavior Safari does not accept "SameSite=Lax"-cookies loaded via a cross-site iframes and behaves like Chrome and Firefox. ## Actual behavior Safari accepts "SameSite=Lax"-cookies loaded via a cross-site iframes. ## Relevant spec https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis-05#section-5.3.7.1 The spec only defines what to *send*, not what to *set*. So I guess Safari doesn't violate the spec, but the current behavior is still confusing. ## Additional information I created a test case reduction in this repository: https://github.com/jaylinski/safari-same-site-cookie Please refer to the `readme.md` for how to set it up. This was tested on latest Safari Technology Preview 131. This is probably not a security issue, but it can create undesired side-effects. In my case, the current behavior caused issues with overwritten session-cookies.