Open bayotop opened 3 years ago
Thanks for reporting this! I can reproduce this issue. I'll try to find someone familiar with this matter and get their opinions.
I got an answer from koto:
It's not a bug I think. Every realm (a document, or a worker) needs its own policies, so in this case the default policy should be also created in the worker code before doing importScripts
Don't think there's anything we can do (maybe intercept the request and inject Trusted Types?)
I think that makes sense. On first sight, it seems a little inconsistent though that script1.js
still uses the default policy defined in index.html, but there might be a reasonable explanation for that too, I guess.
The injection might be doable if extensions can tell something is requesting a web worker and prepend a default trusted type definition to the response.
I also ran in same issue in chrome version 86. Scripts (http://165.227.165.4/web-worker-trusted-types/index.html) works fine on chrome version 100 and later. Not sure in which exact version issue was fixed.
Hey, I stumbled upon a similar issue as https://github.com/filedescriptor/untrusted-types/issues/1 (
This document requires 'TrustedScriptURL' assignment.
) for websites that leverage web workers. It seems that Chrome isn't using thedefault
policy as a fallback in case strings are passed toimportScripts()
resulting in errors since the CSP enforces trusted types.The minimal POC to reproduce this is:
index.html
script1.js
script2.js
Here's a live version http://165.227.165.4/web-worker-trusted-types/index.html
I couldn't find much information regarding this behaviour, however, my gut feeling tells me this might be a bug in Chrome, but I'm not too familiar with web workers (and how they work with trusted types). Just thought that I'll mention it here if others run into it (not sure there is anything the extension could do in these cases).