KhronosGroup/WebGL

Tests fail/hang with content security policy errors

Closed this issue · 5 comments

The following test and some others fail with Content Security Policy errors in Chrome and Firefox because of the script source for the worker.

https://registry.khronos.org/webgl/sdk/tests/conformance/offscreencanvas/offscreencanvas-timer-query.html?webglVersion=2&quiet=0&quick=1

The specific errors are:

offscreencanvas-timer-query.html?webglVersion=2&quiet=0&quick=1:71 Refused to create a worker from 'blob:https://registry.khronos.org/aeca83f9-6e09-4b94-a436-3a726e090610' because it violates the following Content Security Policy directive: "script-src 'self' 'unsafe-inline' 'unsafe-eval' cdnjs.cloudflare.com www.googletagmanager.com www.google-analytics.com". Note that 'worker-src' was not explicitly set, so 'script-src' is used as a fallback.

(anonymous) @ offscreencanvas-timer-query.html?webglVersion=2&quiet=0&quick=1:71
offscreencanvas-timer-query.html?webglVersion=2&quiet=0&quick=1:71 Uncaught DOMException: Failed to construct 'Worker': Access to the script at 'blob:https://registry.khronos.org/aeca83f9-6e09-4b94-a436-3a726e090610' is denied by the document's Content Security Policy.
    at https://registry.khronos.org/webgl/sdk/tests/conformance/offscreencanvas/offscreencanvas-timer-query.html?webglVersion=2&quiet=0&quick=1:71:20

@KhronosWebservices , would you be able to try to fix this? It's not easy for me to experiment with the CSP and figure out what will work. Per https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/Sources I think perhaps strict-dynamic needs to be added to the script-src or worker-src policy, but I'm not sure.

@kenrussell was mostly correct, adding 'strict-dynamic' to worker-src resolved the issue nicely for Chrome, adding blob: to worker-src fixed the Firefox issue. Thank you for the pointer on this one. This issue has been resolved. Please close if after testing on your end, all works as you expect it to.

@outofcontrol
That works fine now. Thanks for fixing this quickly.

Thank you @KhronosWebservices for the quick fix and @aardgoose for reporting the problem!