filedescriptor/untrusted-types

Errors when web workers use importScripts()

bayotop opened this issue · 4 comments

bayotop commented

Hey, I stumbled upon a similar issue as #1 (This document requires 'TrustedScriptURL' assignment.) for websites that leverage web workers. It seems that Chrome isn't using the default policy as a fallback in case strings are passed to importScripts() resulting in errors since the CSP enforces trusted types.

The minimal POC to reproduce this is:

index.html

<!doctype html>
<html>
<head>
    <meta http-equiv="Content-Security-Policy" content="require-trusted-types-for 'script'">
</head>
<body>
<script>
trustedTypes.createPolicy('default', {
  createHTML: string => string,
  createScript: string => string,
  createScriptURL: string => string
});

var worker = new Worker("script1.js");

</script>

script1.js

console.log('hi, from script1.js');
importScripts('script2.js');

script2.js

console.log('hi, from 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).

filedescriptor commented

Thanks for reporting this! I can reproduce this issue.
I'll try to find someone familiar with this matter and get their opinions.

filedescriptor commented

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?)

  • 👍1
bayotop commented

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.

pushpagarwal commented

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.