-
-
Notifications
You must be signed in to change notification settings - Fork 380
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
Dedicated worker file instead of a Blob #139
Comments
Maybe I am just missing the point, but can you explain why using a blob is problematic? If your CSP controls which domains can load scripts onto your page (and assuming you use https, because if not, then security is entirely defeated), that means that the only code that can load a blob worker is already trusted code. And in fact, it is already code that is running on the page, so if it wanted to do something malicious, it already can do it. I'm sure I am missing something, but I would like to understand what that is. |
https://stackoverflow.com/questions/63119217/csp-worker-src-blob-security Allowing "blob:" can't be done for just one package, and it opens the gate for arbitrary code execution across the whole app. If someone manages to get code injected that bypasses CSP somewhere, they can use this other security hole to do further XSS and easily run dynamic code. I'd rather not poke a hole in CSP for dynamic code unless it's absolutely necessary for something business-critical. I'd also prefer to have static code that can be inspected / debugged / handled by Webpack & Babel, instead of dynamic code that only exists at runtime. |
Additionally, it's hard to figure out what code is actually used by the worker since an entire copy of the module is injected into the worker, including the code that was just used to start the worker and inject the code. I assume that area is dead code, since there aren't going to be recursive workers. I assume there's also a bit more dead code that is not actually touched by the worker, and it only uses a subset of the module, but this "only one source file" design feels a bit of an awkward way to structure the code, instead of having 1) module code, 2) worker code, and 3) shared code, broken down into their own distinct files. If the built distribution of If I had a dedicated source file for the worker I could simply direct Webpack to build it separately from the main bundle code, and use a worker URL instead of a Blob (Via |
I don't have time to work on this at this time. If anyone wants to send a PR, please feel free. |
We don't have plans of enabling arbitrary code execution via Blob in Workers, but we're fine with enabling Workers.
Could there be a version of this with a dedicated worker file instead of a Blob? Requiring a build via Webpack is fine, but the
main.toString()
is a bit of a problematic way of injecting the code there.The text was updated successfully, but these errors were encountered: