-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
'strict-dynamic' should bless programmatically added workers #200
Comments
Yeah, I think this makes sense. It's "the same" as a script loading another script. |
In fact, it makes so much sense that it's actually already what the spec says, with a tiny caveat that I forgot to update along with /cc @ckerschb, @mozfreddyb, @dveditz, FYI. |
(20b9193 was the tiny caveat) |
Yay! |
@mikewest Does this also cover the case of importScripts() when executed from inside a worker? I kind of conflated the two in the description above, but maybe this should be a separate bug if the spec requires a different change (or an explanatory note). |
From a spec perspective, yes. From a Chrome perspective, maybe? I didn't check, but it might work! Maybe! Write a test, file a bug if it fails. :) |
You're right, this works for me in Chrome canary already: https://arturjanc.com/csp/workers/service-worker-external-importscripts.html Thanks! |
Huzzah! |
(Would you mind turning that into a web platform test so we can lock in the behavior and not accidentally regress in the future, @arturjanc? :) ) |
According to the current version of the spec (https://w3c.github.io/webappsec-csp/#changes-from-level-2), the loading of workers will be subject to script-src if the policy doesn't explicitly set worker-src.
Many policies don't explicitly set worker-src, which is fine for most whitelist-based policies because workers which match the script-src whitelist will still be allowed (or the developer can expand script-src to cover the locations of such workers). For policies based on 'strict-dynamic', however, the script-src whitelist gets ignored which means that the application cannot create new workers (at least without adding worker-src to the policy which can be undesirable for other reasons).
To address this we should allow code such as
new Worker(...)
to allow the loading of arbitrary resources if the worker policy contains 'strict-dynamic'; this is consistent with the behavior of other non-parser-based APIs such asdocument.createElement
which allow the loading of all scripts.Similarly, once we're executing a worker, if the policy governing the worker contains script-src 'strict-dynamic' we should bless importScripts() and allow it to load arbitrary worker scripts.
The text was updated successfully, but these errors were encountered: