Skip to content

Add the "speculationrules" destination #1841

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Add the "speculationrules" destination #1841

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 8 additions & 4 deletions fetch.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1780,6 +1780,7 @@ the empty string,
"<code>script</code>",
"<code>serviceworker</code>",
"<code>sharedworker</code>",
"<code>speculationrules</code>",
"<code>style</code>",
"<code>track</code>",
"<code>video</code>",
Expand Down Expand Up @@ -1821,13 +1822,16 @@ not always relevant and might require different behavior.
<th>CSP directive
<th>Features
<tr>
<td rowspan=21>""
<td rowspan=22>""
<td>"<code>report</code>"
<td rowspan=2>&mdash;
<td rowspan=3>&mdash;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure this is accurate? Wouldn't this be governed by connect-src at least?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, per discussion with CSP folks, header-initiated fetches are not generally governed by CSP at all. The reasoning is that CSP is a mechanism for protection against HTML injection defense, not header-injection defense; if an attacker can inject headers, then they can mess up your CSP and do all sorts of bad things.

I guess Link might be governed by CSP, but that's more of a historical accident...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I agree with that.

I think it also depends on the order the headers are processed in. If the CSP header is processed first (and I hope that it is), any fetch following it would automatically be subject to CSP.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, not sure, probably something to discuss with the CSP spec editors if you want to make changes to that policy...

Copy link
Member

@annevk annevk Sep 24, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@antosart mind chiming in?

I think in the HTML standard we create a policy container from navigation response first thing and I wouldn't expect us to fetch anything else before that is complete. (This happens deep into https://html.spec.whatwg.org/#create-navigation-params-by-fetching if I'm reading things correctly.)

Are you also suggesting for instance that we would not take Referrer Policy into account here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand correctly, fetches do indeed happen after the policy container is created from the navigation response. However, the current proposal is to have Speculation-Rules headers explicitly bypass CSP by allowlisting the "speculationrules" destination in CSP (w3c/webappsec-csp#776). Digging a bit, that seem to be the result of experiments and discussion (see https://chromestatus.com/feature/5123809745829888?gate=5093909324365824).

I expect the reason for this to be rooted in the attempt of CSP to do (at least) two things at the same time, i.e. control script execution and gate outgoing requests (which in the case of script-src end up colliding even if they are conceptually distinct - fetching a script content is not the same as executing it). Gating the Speculation-Rules header behind script-src would make it impossible to use the feature with strict CSP. Gating it behind something else (e.g. connect-src) could be somehow confusing given that the other way to specify speculationrules is in a script tag (for which script-src does apply). It's not totally clear to me what the best option is here, but I think it would make sense to have some record/explanation of why the choice was made.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think that the usage of <script> necessarily implies script-src. script-src makes sense when the result is script execution, but if we were to use <script> for JSON modules or some such it shouldn't use script-src but the same thing that the "json" destination devolves into. I think the same kind of rationale applies here, which I suspect means connect-src in the end.

I know some at Google don't care about the exfiltration angle of CSP, but I don't think we have ever reached agreement on giving up on it, so until we get there I think new fetch contexts should play by the same rules as existing ones.

<td>CSP, NEL reports.
<tr>
<td>"<code>document</code>"
<td>HTML's navigate algorithm (top-level only).
<tr>
<td>"<code>speculationrules</code>"
<td>The [:Speculation-Rules:] header
<tr>
<td>"<code>frame</code>"
<td><code>child-src</code>
Expand Down Expand Up @@ -1887,7 +1891,7 @@ not always relevant and might require different behavior.
<tr>
<td>"<code>webidentity</code>"
<td><code>connect-src</code>
<td><code>Federated Credential Management requests</code>
<td>Federated Credential Management requests
<tr>
<td>"<code>worker</code>"
<td><code>child-src</code>, <code>script-src</code>, <code>worker-src</code>
Expand Down Expand Up @@ -7560,7 +7564,7 @@ dictionary RequestInit {
any window; // can only be set to null
};

enum RequestDestination { "", "audio", "audioworklet", "document", "embed", "font", "frame", "iframe", "image", "json", "manifest", "object", "paintworklet", "report", "script", "sharedworker", "style", "track", "video", "worker", "xslt" };
enum RequestDestination { "", "audio", "audioworklet", "document", "embed", "font", "frame", "iframe", "image", "json", "manifest", "object", "paintworklet", "report", "script", "sharedworker", "speculationrules", "style", "track", "video", "worker", "xslt" };
enum RequestMode { "navigate", "same-origin", "no-cors", "cors" };
enum RequestCredentials { "omit", "same-origin", "include" };
enum RequestCache { "default", "no-store", "reload", "no-cache", "force-cache", "only-if-cached" };
Expand Down