More robust handling of non-executable <script> nodes

[arturjanc]

There's a number of new proposals using <script> elements to deliver configuration which doesn't execute as a script, but has the ability to affect the behavior of the page; two examples include import maps and speculation rules (intent thread).

This makes me worry about situations where a script isn't subject to CSP, but can affect the behavior of the page in significant ways; that's because it's possible to have a <script> that isn't checked against CSP in HTML's prepare a script algorithm:

Content-Security-Policy: script-src 'nonce-foo'

<!-- Neither script below results in a script-src violation -->
<script type="foobar">foo</script>
<script type="importmap" src="foo"></script>

It looks like at least the import maps spec considers the integration with CSP (https://wicg.github.io/import-maps/#integration-prepare-a-script), but I wonder if there's a change to HTML that would make the check happen by default for every <script>?

@mikewest @domenic

[domenic]

I think it does happen for every script, because every script goes through "prepare a script". Import maps makes a non-normative note of this fact, whereas speculation rules doesn't, but it's the same for both (and for any future scripts).

[arturjanc]

I'm certainly happy if this means that we don't have to do anything here! But doesn't the fact that a script with an unknown type (like in the example above) is allowed by the CSP suggest there's some risk of introducing new types for which CSP will no longer be enforced? IOW would there be any benefit to moving the CSP check up in the "prepare a script" algorithm?

[domenic]

It's not clear to me what you mean by "allowed".

All scripts go through "prepare a script". If they have any useful processing model, they make it past step 8. Otherwise we bail and do nothing. CSP checks are then done on every script with a processing model, in step 15. (Steps in between 8 and 15 are mostly other bail-out cases, e.g. empty script, not-connected script, scripting disabled, ...)

So types with no processing model (e.g., types used by page authors to embed data, such as in the first example below https://html.spec.whatwg.org/#dom-script-text) bail early, and generate no CSP violations. But the moment one adds a processing model for the script, CSP will automatically start applying, and disallowing the script if applicable.

[jeremyroman]

I wonder whether we'll eventually want to allow it to check a directive other than script-src. Speculation rules seem like authors may want to automatically generate them and unless we provide a separate imperative API authors will need to generate <script> tags with a nonce that matches the CSP, or allow all inline scripts to execute.

That seems like a mild hassle that would be avoidable if we had a speculation-rules-src directive that could be given unsafe-inline without doing it to all scripts -- but it is only a mild hassle.

[arturjanc]

Thank you for the detailed explanation, Domenic! Based on the fact that scripts that have a processing model will be subject to CSP checks (and scripts that don't have one seem equivalent semantically to any other element), I think the spec is doing what we want it to do, so I'm inclined to close this issue.