Intent to Ship: WebAssembly Content Security Policy

Skip to first unread message

Francis McCabe

Sep 23, 2021, 5:36:20 PM9/23/21
to blink-dev

Contact emails



Design docs


Enhancements to Content Security Policy to improve interoperability with WebAssembly.

The change involves adding a new CSP source keyword: wasm-unsafe-eval that would allow a web page to compile and execute WebAssembly modules. 

Blink component


Search tags


TAG review

Not needed in our view, as this is a very small change to existing CSP functionality.

TAG review status


Interoperability and Compatibility



Web developers: There has been a considerable amount of discussion of this within the WebAppSec WG and there is some pressure from developers to adopt this (see and and


Is this feature fully tested by web-platform-tests?

Yes * CL under review

Flag name

Blink feature flag WebAssemblyCSP

Requires code in //chrome?


Tracking bug

Estimated milestones


Link to entry on the Chrome Platform Status

Mike West

Sep 30, 2021, 3:15:04 PM9/30/21
to Francis McCabe, blink-dev

We've talked about this approach in WebAppSec a few times, and I think there's general agreement on the approach. I'd like to see the spec language land before shipping this, but it looks like there aren't any substantive outstanding questions, and I'm confident you can work out the details.


You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit

Daniel Bratell

Sep 30, 2021, 3:19:06 PM9/30/21

Hi Francis,

I read in the explainer that you had explored reusing currently exiting script-src policies but thought that would break existing content. Could you expand a bit on how you reached that conclusion?


Francis McCabe

Oct 5, 2021, 3:15:44 PM10/5/21
to blink-dev, Daniel Bratell
Note: this was pointed out to me by mkwst@ ... 
The scenario is that a web site publishes a script-src policy (without otherwise mentioning webassembly), not expecting it to enable any wasm execution. Extending the coverage of script-src would extend the footprint of files accessible from that developer's domain.
Note: in discussion between mkwst@ and, they agreed that this is not necessarily a serious extension. I am not personally sure of the conclusion they reached.

In the end, there was consensus multiple levels that it would (a) not be a good idea to  extend script-src and (b) to have a new policy source tailored for WebAssembly. Tentatively called 'wasm-src'. One potential feature of this could be that it would not support any white listing of domains; i.e., only use nonces (hashes don't seem to be a good fit because wasm files can be extremely large).

However, any new wasm-src policy effort will take significant time to develop and this proposal should not be gated on that.

I hope that this helps.


Oliver Dunk

Oct 6, 2021, 2:05:26 PM10/6/21
to blink-dev, Francis McCabe
Hey! Just to confirm, it seems like this change wouldn't impact extensions at all? My understanding is that the current implementation supports extensions by adding the chrome-extension:// URL scheme to an allow-list. With that in mind, I imagine the implementation here would be removing that allow-list but keeping the behaviour for extensions otherwise the same?

Francis McCabe

Oct 6, 2021, 6:11:48 PM10/6/21
to blink-dev,, Francis McCabe
Confirming: there is no current plan to modify how extensions would work.
I was alluding to semi-solid thoughts on how a possible wasm-src policy would work. But, in any case, wasm-unsafe-eval would continue even without any new wasm-src.

Also, currently, extensions (and only extensions and chrome apps), can use the 'wasm-eval' policy source keyword. There was a lot of discussion about using wasm-eval for normal web pages but the community eventually decided against doing that.

wasm-eval will continue to work for extensions. But, IMO, that sets up a problem for the future. Chrome extensions will be able to use wasm-eval; but noone else will (they will have to use wasm-unsafe-eval, or, in the future, a wasm-src policy). I can see there being some pressure to normalize this down the road.

Yoav Weiss

Oct 7, 2021, 3:25:58 AM10/7/21
to Francis McCabe, blink-dev,, Francis McCabe

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to

Daniel Bratell

Oct 7, 2021, 3:58:29 AM10/7/21
to Yoav Weiss, Francis McCabe, blink-dev,, Francis McCabe
Reply all
Reply to author
0 new messages