Sec-Fetch-Site values are supposed to provide information about the relationship between a request initiator's origin and the origin of the requested resource (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Site and https://w3c.github.io/webappsec-fetch-metadata/#sec-fetch-site-header) However, when the following iframe is included on the page, the value of the Sec-Fetch-Site header will be "none": <iframe method="get" referrerpolicy="no-referrer" src="https://www.example.com"></iframe> It appears to be due to referrer policy attribute. Setting it to no-referrer will cause Safari to send Sec-Fetch-Site header with "none" value regardless of the origin the iframe i.e. same-origin, same-site and cross-site frames would all have this header set to "none". --- Reproduction steps: 1. Open any website, e.g. example.com 2. Open developer tools and paste the following code in the JS console: ``` const iframe = document.createElement('iframe'); iframe.src = 'https://www.example.com'; iframe.referrerPolicy = 'no-referrer'; iframe.method = 'get'; document.body.appendChild(iframe); ``` 3. Inspect the request headers send on the iframe request. Expected Outcome: The Sec-Fetch-Site header is set to same-origin, same-site and cross-site, etc. Actual Outcome: The Sec-Fetch-Site header is set to none.
Created attachment 466295 [details] fetch-metadata-iframe-no-referrer-test.patch Attached is a test case for this. Will look into it further.
<rdar://problem/109358563>
So the problem is pretty clear in that `CachedResourceLoader::computeFetchMetadataSite()` should not be using referrer information to calculate this. I'm having a hard time finding information to detect if a navigation was "user-initiated" though. All the APIs that seem interesting like: - DocumentLoader::lastNavigationWasAppInitiated() - Navigation::wasUserInitiated() - LocalFrame::hasHadUserInteraction() All return not useful values on macOS Safari.
Why would user-initiated matter here?
(In reply to Anne van Kesteren from comment #4) > Why would user-initiated matter here? To quote MDN for example: > none > This request is a user-originated operation. For example: entering a URL into the address bar, opening a bookmark, or dragging-and-dropping a file into the browser window.
Patrick, two things: 1. Best not to look at MDN to figure out what to implement. https://w3c.github.io/webappsec-fetch-metadata/ is the relevant specification. 2. Looking at https://w3c.github.io/webappsec-fetch-metadata/#abstract-opdef-set-site step 4 and the explanation linked there makes it clear to me that when navigating a nested document "none" can never be correct. A user-initiated navigation as meant there would always involve a top-level navigation.
In addition to referrerpolicy, it seems the Sec-Fetch-Site behavior is also incorrect for sandboxed iframes: https://bugs.webkit.org/show_bug.cgi?id=260284
(In reply to Anne van Kesteren from comment #6) > Patrick, two things: > > 1. Best not to look at MDN to figure out what to implement. > https://w3c.github.io/webappsec-fetch-metadata/ is the relevant > specification. The spec you linked says the exact same things: https://w3c.github.io/webappsec-fetch-metadata/#directly-user-initiated
Patrick, but none of that applies to a nested document navigation, right?
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.
Committed 277662@main (ab5d20c0ff15): <https://commits.webkit.org/277662@main> Reviewed commits have been landed. Closing PR #27350 and removing active labels.