<link>-based API should be subject to CSP

[lweichselbaum]

Since <link rel="webbundle" ..> can be used to load or redirect loads of scripts it should be subject to CSPs script-src directive.
Especially the CSP nonce attribute should be verified in case a CSP restricts script loading based on nonces.

I.e. in the presence of a Content-Security-Policy script-src 'nonce-random123' header only <link rel="webbundle" nonce="random123" ..> should be allowed to execute.
Same holds true for <script type=”module” ..> or similar declarative script loading mechanisms.

/ cc @mikewest @arturjanc @koto

[mikewest]

It surprises me that we'd directly execute script via <link rel="webbundle" ...>. Is that the case?

[koto]

I don't think it is directly. Web bundles <link> proposal aims to hijack subsequent fetches for subresources, and direct them to the URLs that tentatively are part of the bundle - instead of to the network. In that regard, it's similar to a declarative service worker.

[mikewest]

/cc @jyasskin @horo-t

[lweichselbaum]

I think we have similar restrictions for <link rel=preload as=script ..> which are subject to CSP nonces as well.

[kinu]

isn't supposed to directly execute scripts or anything, right. So when <script ...> executes a script from it should respect to script-src CSP.

[mikewest]

isn't supposed to directly execute scripts or anything, right. So when <script ...> executes a script from it should respect to script-src CSP.

Thanks, @kinu! I have a few questions:

1. Which directive controls the request that <link rel="webbundle" ...> generates?
2. How is the <script> evaluation performed? Against the URL in the src attribute? Against the URL of the resource that's actually being used?
3. I'm assuming that the mechanism here only works with signed bundles, and not unsigned?

[jeffkaufman]

How is the <script> evaluation performed? Against the URL in the src attribute? Against the URL of the resource that's actually being used?

Today the former, but in #651 I'm proposing switching to the latter