I've put together a quick example here: https://s3.amazonaws.com/webassembly-chrome-csp/csp_test.html

I think the goal was for user-agents to become consistent in how they interpret unsafe-eval and wasm-eval directives. Issue #1 discussed how not to, and issue #2 touches on how to, but I'm not sure if consensus has been reached.

Right now Chrome restricts 'wasm-eval' to web apps because it's not part of the CSP standard. I'm going to try to put together a PR this week to move along the process of making 'wasm-eval' standard, at which point it should be pretty straightforward for Chrome to expose 'wasm-eval' to the web.

Awesome.

Out of curiosity, I just tried running your test case on Safari and got:

[Error] TypeError: WebAssembly.instantiateStreaming is not a function. (In 'WebAssembly.instantiateStreaming(fetch('simple.wasm'), importObject)', 'WebAssembly.instantiateStreaming' is undefined)
	Global Code (csp_test.js:3)

Does that match what you see? Based on the table on the Wasm CSP Proposal, Safari should not allow instantiate or instantiateStreaming without 'unsafe-eval'.

Safari currently doesn't implement streaming.

I just submitted the PR for 'wasm-eval': w3c/webappsec-csp#293

Has there been any movement on this? Looks like the PR has been open for over 4 months now.

The CSP proposal stalled out as @eholk has moved on to another team. However, @titzer is starting to help out now.

Awesome, thanks for pushing this forward.

So just for the sake of clarity, the end goal here will be to create a CSP that allows WASM without allowing unsafe-eval of everything? I'm also looking at incorporating WebAssembly into my application and ran into this issue, so was hoping unsafe-eval wasn't the only way out.

Also, unrelated question: why do I not receive this warning on Firefox?

@twilco Yes, the proposed wasm-eval (or maybe unsafe-wasm-eval) would be a separate directive that enables WASM code generation independent of JavaScript's eval.

There's a PR #17 to rename the directive. However, for Chrome apps that use extension URLs, we'll likely keep the old directive for some transition time.

So has wasm-unsafe-eval been implemented in chrome and in which version ?

Hi, we've only implemented wasm-eval (preliminary name) in Chrome for extension URLs. The new name wasm-unsafe-eval (and applying to all URLs) has not yet been implemented. Given that this proposal seems to be (slowly) iterating to a decent state, I think we can begin implementation soon.

Either treating the Response object as an origin according to the given CSP

I wish to be able to use WebAssembly from my extension -- this is already the case for the Firefox version of the extension.

However, I do not plan to use wasm-unsafe-eval if/when it becomes available, as this goes against the spirit of not executing remote code.

What is the reason Chromium can't allow loading of wasm modules from same-origin Response objects? This would solve the issue of loading/executing only same-origin wasm code (i.e. the extension's packaged files) without having to resort to relaxing the default CSP in the manifest.

I opened a bug on the Chromium bug tracker for implementing wasm-unsafe-eval: https://bugs.chromium.org/p/chromium/issues/detail?id=948834&can=1&q=wasm-eval Please star it if you're interested in following updates.

I've filed Support origins and SRI-style hashes in CSP for WebAssembly streaming APIs to address the concerns of @gorhill and myself.

Hi there - @hackcasual - I am running into this error when attempting to embed Google Street View in a dashboard in Tableau Online. I am new to coding and am curious if this conversation, particularly what you mentioned about Tableau, has to do with this error and if it's resolvable:

TYIA!

Hi @kendraspock , that error is a direct result of this. It's a little confusing since it doesn't actually mean Chrome refused to compile the WebAssembly module, it's reporting that if CSP were enabled, it would refuse to compile the module. It's benign.

I implemented successfully a compression protocol called Brotli here:
http://udpx.fasani.de
(It's an old fashioned Chrome app)
Even if wasm-eval seems to work I see that on many Web Assembly existing libraries they use eval() so that is a big restriction to use them for me right now. The funny thing is that I had to upload the binary WASM on a server just to give it back with the right CSP:

header("Content-Type: application/wasm");
header("Access-Control-Allow-Origin: *");

otherwise it won't work, but I though apps restrict scripts from remote URLs.

@coderanger tracked down a Chrome bug report for the errant behaviors above.clap The situation remains as per the title of this issue: We have to add script-src unsafe-eval to enable WebAssembly (and that works, despite the errors displayed) until a better, wasm-specific option is available. https://bugs.chromium.org/p/chromium/issues/detail?id=915648

@coderanger
Unfortunately that does not work for me, no matter if I use unsafe-eval or wasm-eval.
I created a repo to make the problem reproducible: https://github.com/flosse/wasm-browser-extension-test
Can you identify the problem or misunderstanding?

Closing

Considering it is closed, can someone point me to which comment in this thread remedies the situation described here:
The Firefox version of uBO makes use of WebAssembly code for core filtering code paths. This is not the case with Chromium-based browsers because this would require an extra permission in the extension manifest which could cause friction when publishing the extension in the Chrome Web Store. --
https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-best-on-Firefox

A small follow-up. We are 'looking into this'. Not a whole lot to report yet.

@fgmccabe So you were looking into this, is there any result yet?
And if you are looking into this, could you probably open this issue again to show that it is "in progress" as you say?

Ah or is not this fixed by w3c/webappsec-csp#293?

Apparently Chrome 97 now supports a directive called wasm-eval.

@rugk wasm-eval does nothing, At least on Linux x86_64 tested with Chromium v99. Others have mentioned it earlier as well, Currently we're forced use 'unsafe-eval' if we need wasm.

wasm-eval is/was always restricted to chrome extensions and chrome apps. For manifest v3, it will likely not be supported.
The correct csp source keyword to use is wasm-unsafe-eval.
This has been supported in chrome since m97. A patch to fix it for manifest v3 is rolling out at the moment.

Thanks for clarifying, wasm-unsafe-eval works for my web app.

wasm-eval is/was always restricted to chrome extensions and chrome apps. For manifest v3, it will likely not be supported. The correct csp source keyword to use is wasm-unsafe-eval. This has been supported in chrome since m97. A patch to fix it for manifest v3 is rolling out at the moment.

Thanks!

I've put together a quick example here: s3.amazonaws.com/webassembly-chrome-csp/csp_test.html

Thanks for clarifying, wasm-unsafe-eval works for my web app.

@abishekmuthian
I might be missing something but switching the CSP to the following still doesn't work in either Chrome 109, Firefox 109 or Safari 16.2:

<meta http-equiv="Content-Security-Policy" content="script-src 'self' 'wasm-unsafe-eval'">

I noticed lighthouse itself complains about CSP and 'wasm-unsafe-eval' fixes the problem. I wonder the security implications of wasm-unsafe-eval in particular for those who don't use wasm

Can you be more specific?
wasm-unsafe-eval is specified to only impact WebAssembly execution

@fgmccabe Sure, I was running lighthouse from dev-tools itself with

script-src 'none';

That was mysteriously lowering the Best Practices score to 92. Then I ran CSP with report only mode and it pointed out the lighthouse tool itself was using web assembly to do its diagnosis.

So I changed it the following and now score is back to 100% :

script-src 'wasm-unsafe-eval';

P.S my page itself doesn't use WASM anywhere.

Got it.