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.
Created attachment 470285 [details] External script file
<rdar://problem/124410909>
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
(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
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
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 :)
Thanks a lot Fotis. This is super helpful. This is being tracked internally too.
Pull request: https://github.com/WebKit/WebKit/pull/32365
Pull request: https://github.com/WebKit/WebKit/pull/32449
Committed 282577@main (88833ba4cdcb): <https://commits.webkit.org/282577@main> Reviewed commits have been landed. Closing PR #32449 and removing active labels.