Bug 270784 – CSP: External script with matching SRI hash is blocked when 'strict-dynamic' is present in script-src

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[Fotis Papadogeorgopoulos]

Created attachment 470284 [details]
HTML file that loads an external script with SRI hash

When `script-src 'strict-dynamic'` is present in a CSP, external scripts with matching SRI hashes (via `integrity`) are blocked.
If 'strict-dynamic' is removed, then scripts with a matching SRI are allowed (subject to the regular CSP hash checks).

We recently ran into this at wolt.com, when migrating to a new CSP design. We rely on 'strict-dynamic' with external script SRI hashes for our script loading. This works as expected on Firefox and Chrome, but I admit that I am not super familiar with the spec, to make a call either way :)

At the moment, we have to use user agent sniffing to avoid the scripts getting blocked on Safari, which is not ideal. We would like to understand whether this blocking is intended or incidental.

CSP for external script SRI hashes was implemented at https://bugs.webkit.org/show_bug.cgi?id=233911, but it does not specifically address 'strict-dynamic', as far as I can tell.

I have a reproduction at https://github.com/fpapado/csp-strict-dynamic-external-script-hash and a PR for WPT, if that runner is more familiar https://github.com/web-platform-tests/wpt/pull/44769. I am also attaching an index.html file, but there is a single attachment limit, so it is not useful by itself.

Please let me know if there is any other information that I can provide, and I will get back to you promptly! It's likely I missed something.

[Fotis Papadogeorgopoulos]

Created attachment 470285 [details]
External script file

[Radar WebKit Bug Importer]

<rdar://problem/124410909>

[Karl Dubost]

Maybe it would be worth to create additional WPT tests for this. 
https://wpt.fyi/results/content-security-policy?label=master&label=experimental&aligned&q=safari%3Afail%20firefox%3Apass%20chrome%3Apass

[Fotis Papadogeorgopoulos]

(In reply to Karl Dubost from comment #3)
> Maybe it would be worth to create additional WPT tests for this. 
> https://wpt.fyi/results/content-security-
> policy?label=master&label=experimental&aligned&q=safari%3Afail%20firefox%3Apa
> ss%20chrome%3Apass

Definitely, if I am reading it right, there is a gap for this case in WPT at the moment.

I made a start in this PR https://github.com/web-platform-tests/wpt/pull/44769, adding a case to the existing content-security-policy/script-src/script-src-strict_dynamic_hashes tests. I am not super familiar with authoring WPT though, so I might have missed more idiomatic ways of making those assertions :)

Here is the deployed preview branch from WPT's CI: https://wpt.fyi/results/content-security-policy/script-src/script-src-strict_dynamic_hashes.html?label=pr_head&max-count=1&pr=44769

[Karl Dubost]

Fotis,

Anne
left a comment on https://github.com/web-platform-tests/wpt/pull/44769#issuecomment-2048945493
and opened https://github.com/w3c/webappsec-csp/issues/653

[Fotis Papadogeorgopoulos]

Hi Karl! Thank you and Anne for the help with this. 

The spec has now been changed to clarify this behaviour (https://github.com/w3c/webappsec-csp/issues/653) and the WPT test is merged (relevant view: https://wpt.fyi/results/content-security-policy/script-src/script-src-strict_dynamic_hashes.html?label=master&label=experimental&aligned&q=safari%3Afail%20firefox%3Apass%20chrome%3Apass).

Please let me know if there is anything else I can do on my side. Otherwise, happy to leave this to you all. Thanks again :)

[Karl Dubost]

Thanks a lot Fotis. This is super helpful.
This is being tracked internally too.

[Yesudeep Mangalapilly]

Pull request: https://github.com/WebKit/WebKit/pull/32365

[Luke Warlow]

Pull request: https://github.com/WebKit/WebKit/pull/32449

[EWS]

Committed 282577@main (88833ba4cdcb): <https://commits.webkit.org/282577@main>

Reviewed commits have been landed. Closing PR #32449 and removing active labels.