Consider relaxing prefetch-src and preload as

[noamr]

Reading through past decision like introducing prefetch-src and yet-to-be-decided issues like CSP for preconnect and dns-prefetch, I believe we can improve the way these resource hints integrate with CSP. I would like to propose an alternate viewpoint.

The goals of CSP are to prevent:

• content injection
• to some extent, exfiltration

A preload and a prefetch (and to a greater degree, preconnect and dns-prefetch) are not in themselves able to "inject content" - their content is not used by the document until discovered by a subsequent fetch that would have to pass CSP checks again. IIUC, the only risk with those hints is exfiltration. Unless there are things CSP comes to prevent that I'm anaware of.

With content injection, the type of resource matters. e.g. you want to allow embedding an image from some particular CDN, but not execute scripts.

But with exfiltration, the type of resource does not make any difference. If cross-origin images are allowed but not scripts, you can still send out requests by piggy-backing them on images.

So, the only way to really prevent exfiltration, is by having something like default-src: none or default-src: self - thus preventing all types of resources from making requests.

So my suggestion is:

• Resource hints, including prefetch, preconnect, dns-prefetch (and optionally preload without as) would default to the most lenient directive in the current policy regarding the URL in question
• prefetch-src would still be valid, as a way to relax restictions only for resource hints

[noamr]

/cc @mikewest @annevk @yoavweiss

[annevk]

That seems reasonable.

[hiroshige-g]

a subsequent fetch that would have to pass CSP checks again

This is not 100% true for <link rel=preload> because e.g. the subsequent fetch doesn't perform CSP checks on redirects.
Is <link rel=preload> intentionally excluded from the proposal for this reason?

[noamr]

a subsequent fetch that would have to pass CSP checks again

This is not 100% true for <link rel=preload> because e.g. the subsequent fetch doesn't perform CSP checks on redirects. Is <link rel=preload> intentionally excluded from the proposal for this reason?

It's included as long as it doesn't have as. If we can relax preload as, we also can relax its CSP to be the same as prefetch.

[jeremyroman]

Should Fetch be updated to reflect the removal of this? It still refers to prefetch-src.

[noamr]

Should Fetch be updated to reflect the removal of this? It still refers to prefetch-src.

Yes! Good catch, thanks

[annevk]

whatwg/fetch@a48b8ba

[vejja]

+1
Nuxt is facing similar issue as React here.
Would be good if we could also relax preload.
Otherwise <link rel="preload" as="script"> gets blocked even though script itself is authorized.
See nuxt/scripts#280 (comment)