Navigation fetch always uses document destination

[jdm]

What is the issue with the HTML Standard?

https://html.spec.whatwg.org/multipage/browsing-the-web.html#create-navigation-params-by-fetching is the only time a request is created for navigation that I can see. It always uses the "document" destination for the request, even if the navigation occurs within an iframe. This has implications for other specifications like CSP, which use the destination to determine which directives to consult: https://www.w3.org/TR/CSP/#directive-algorithms

[domenic]

This seems to be working as intended. Can you explain further what the problem you're trying to solve is?

[jdm]

By following the spec, frame-src CSP directives will never be consulted when deciding whether to block an iframe's navigation.

[TimvdLippe]

We are trying to figure out why Servo isn't correctly checking CSP for iframes. @jdm are we maybe missing the steps in https://fetch.spec.whatwg.org/#ref-for-concept-request-destination%E2%91%A1%E2%91%A1 ?

[jdm]

We are trying to figure out why Servo isn't correctly checking CSP for iframes. @jdm are we maybe missing the steps in https://fetch.spec.whatwg.org/#ref-for-concept-request-destination%E2%91%A1%E2%91%A1 ?

That's text for spec authors making use of the Fetch infrastructure from other specs.

[TimvdLippe]

Navigation of an iframe starts with https://html.spec.whatwg.org/multipage/iframe-embed-object.html#the-iframe-element:navigate which in step 21.9 of https://html.spec.whatwg.org/multipage/browsing-the-web.html#navigate calls https://html.spec.whatwg.org/multipage/browsing-the-web.html#attempt-to-populate-the-history-entry's-document Here, the navigation params are empty, since that's only called for object or embed. Thus, we end up in https://html.spec.whatwg.org/multipage/browsing-the-web.html#create-navigation-params-by-fetching where we set the destination to document (rather than iframe).

When that ends up in https://www.w3.org/TR/CSP3/#effective-directive-for-a-request we return connect-src rather than frame-src. Alle frame related CSP checks (child-src for example) therefore don't run.

[domenic]

I see, I guess that does seem like a bug.

At this point I don't really understand what the intended architecture was here. CSP does indeed have some frame-ish destinations, but it also has initiators, and seems to imply that CSP should be using initiator instead of destination:

A request’s initiator is not particularly granular for the time being as other specifications do not require it to be. It is primarily a specification device to assist defining CSP and Mixed Content. It is not exposed to JavaScript. [CSP] [MIX]

Do you know what existing browsers do?

[TimvdLippe]

• Chromium implementation passing in destination into the function. It is propagated from the caller from request_info. It is set when creating a navigation request which calls GetDestinationFromFrameTreeNode. It checks the element and changes the destination based on that, including iframes.
• Webkit implementation where destination is stored in FetchOptions. It is set when creating a request which calls destinationForType.
• Gecko I am not sure where navigation happens (they don't comment it). I did find LoadInfo which is set when loading a URI which calls DetermineContentType

It seems that all browsers store this information in {load,request}_info and implement a switch function, either on the element type or from some other internal enum.

[jdm]

I see this in #6315:

+    <p>If <var>navigable</var>'s <span data-x="nav-container">container</span> is non-null:</p>
 
-  <p class="note">The <code data-x="dom-location-href">href</code> setter intentionally has no
-  security check.</p>
+    <ol>
+     <li><p>If the <var>navigable</var>'s <span data-x="nav-container">container</span> has a
+     <span>browsing context scope origin</span>, then set <var>request</var>'s <span
+     data-x="concept-request-origin">origin</span> to that <span>browsing context scope
+     origin</span>.</p></li>
 
-  <p>The <dfn attribute for="Location"><code data-x="dom-location-origin">origin</code></dfn>
-  getter steps are:</p>
+     <li><p>Set <var>request</var>'s <span data-x="concept-request-destination">destination</span>
+     and <span data-x="concept-request-initiator-type">initiator type</span> to
+     <var>navigable</var>'s <span data-x="nav-container">container</span>'s <span
+     data-x="concept-element-local-name">local name</span>.</p></li>
+    </ol>

I no longer see that text in the spec, so we apparently lost it at some point since then.

[jdm]

No, wait, it's just further down the spec from where I originally linked it: step 8 of https://html.spec.whatwg.org/multipage/#create-navigation-params-by-fetching. Apologies for the confusion; this appears to be working as intended.

[TimvdLippe]

Seems like we were not the first ones to be confused: #8383 Should we maybe add a hint in the spec text to make it clearer what the flow is here?

[annevk]

@TimvdLippe if you have a concrete suggestion, ideally in the form of a PR, that would make it easier to consider. I'll reopen this for now to keep track of your request.

[TimvdLippe]

Sure thing! Opened #11318, but I don't know if a note can be rendered as part of a details table. Also, had to use GitHub codespaces, so not sure if I had to run a commit hook for formatting (I remember HTML spec does that)