Bug 256472 – Incorrect Sec-Fetch-Site values on iframes

• Status: RESOLVED
• Resolution: FIXED
• Component: Frames

[Bartosz Niemczura]

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.

[Patrick Griffis]

Created attachment 466295 [details]
fetch-metadata-iframe-no-referrer-test.patch

Attached is a test case for this. Will look into it further.

[Radar WebKit Bug Importer]

<rdar://problem/109358563>

[Patrick Griffis]

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.

[Anne van Kesteren]

Why would user-initiated matter here?

[Patrick Griffis]

(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.

[Anne van Kesteren]

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.

[Jerry Zhang]

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

[Patrick Griffis]

(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

[Anne van Kesteren]

Patrick, but none of that applies to a nested document navigation, right?

[Vincent Lee]

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.

[EWS]

Committed 277662@main (ab5d20c0ff15): <https://commits.webkit.org/277662@main>

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