You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Then this will disallow the execution of eval(), since the CSP directive unsafe-eval has not been passed. However, in Google Chrome it also has the effect of disabling the ability to run any WebAssembly content on the page, giving an error
CompileError: WebAssembly.instantiate(): Wasm code generation disallowed by embedder
However, working with web site hosts, they are generally very hesitant to add support for 'unsafe-eval', because every web developer has by now heard "eval() is bad!". As a result, they are eager to also disallow WebAssembly content to run.
It is unfortunate that WebAssembly.compile() and WebAssembly.instantiate() execution has been likened to eval() in Chrome. While technically true, it is much more difficult to inject WebAssembly.instantiate() based exploits onto a page, compared to plain eval(), because WebAssembly cannot directly access any of the DOM unless one is able to also inject JavaScript code to import some web APIs to it.
I wish to propose that a WebAssembly-specific CSP policy would be added, e.g. 'wasm-eval', that would enable WebAssembly.instantiate() without opening up eval(). That would make web site hosts happy, and allow them to open up the minimal amount of security to let WebAssembly work.
The CSP policy 'unsafe-eval' could certainly still imply 'wasm-eval' capability.
Related, I notice that Firefox does not implement this 'unsafe-eval' CSP behavior. (CC @lukewagner).
Also, I am unsure if WebAssembly.compileStreaming() and WebAssembly.instantiateStreaming() are currently disabled in Chrome if 'unsafe-eval' CSP is not enabled. @dschuff: do you know? My impression is that if 'unsafe-eval' is disallowed on a site, and even if that would/should disable WebAssembly.compile() and WebAssembly.instantiate() capability, it should still by design enable WebAssembly.compileStreaming() and WebAssembly.instantiateStreaming() to work?
The text was updated successfully, but these errors were encountered:
Currently if a site contains a Content Security Policy directive, e.g.
Then this will disallow the execution of
eval()
, since the CSP directiveunsafe-eval
has not been passed. However, in Google Chrome it also has the effect of disabling the ability to run any WebAssembly content on the page, giving an errorOne has to specify
in Chrome to make it work.
However, working with web site hosts, they are generally very hesitant to add support for
'unsafe-eval'
, because every web developer has by now heard "eval() is bad!". As a result, they are eager to also disallow WebAssembly content to run.It is unfortunate that
WebAssembly.compile()
andWebAssembly.instantiate()
execution has been likened toeval()
in Chrome. While technically true, it is much more difficult to injectWebAssembly.instantiate()
based exploits onto a page, compared to plaineval()
, because WebAssembly cannot directly access any of the DOM unless one is able to also inject JavaScript code to import some web APIs to it.I wish to propose that a WebAssembly-specific CSP policy would be added, e.g.
'wasm-eval'
, that would enableWebAssembly.instantiate()
without opening upeval()
. That would make web site hosts happy, and allow them to open up the minimal amount of security to let WebAssembly work.The CSP policy
'unsafe-eval'
could certainly still imply'wasm-eval'
capability.Related, I notice that Firefox does not implement this
'unsafe-eval'
CSP behavior. (CC @lukewagner).Also, I am unsure if
WebAssembly.compileStreaming()
andWebAssembly.instantiateStreaming()
are currently disabled in Chrome if'unsafe-eval'
CSP is not enabled. @dschuff: do you know? My impression is that if'unsafe-eval'
is disallowed on a site, and even if that would/should disableWebAssembly.compile()
andWebAssembly.instantiate()
capability, it should still by design enableWebAssembly.compileStreaming()
andWebAssembly.instantiateStreaming()
to work?The text was updated successfully, but these errors were encountered: