Extending WASM CSP to be covered under `strict-dynamic`

[jeremie-stripe]

In the current specification, it's mentioned that WebAssembly is only integrated with the unsafe-eval and wasm-unsafe-eval stanza for script-src.

Separately, there is also a mode of CSP known as strict-dynamic which allows trust to be given specifically to certain scripts which then carry that trust to (mostly) anything else they would execute dynamically.

Today it seems like this trust is extended to both scripts and worker generated by the initial trusted script but crucially not to WebAssembly code that is attempted to be instantiated from a trust script in this way.

Is this a desired aspect of the specification or something to fix?

[fgmccabe]

This spec, the wasm spec for CSP integration, is limited to wasm-specific operations.
In particular, we have a hook in the module compilation operations (in js-api/index.bs) that invoke the abstract operation HostEnsureCanCompile.

This is an opportunity for the CSP enforcement operations to verify that wasm is allowed. The specifics for how CSP should do this is beyond this particular specification.

(Apologies for the super-late response)

[jeremie-stripe]

Thanks @fgmccabe, if I understand you right, are you suggesting this should be re-opened as an issue in https://github.com/w3c/webappsec-csp because it should be changed in the main CSP spec and enforced by the browser host via HostEnsureCanCompile?

[fgmccabe]

I believe so. The wasm spec focuses on wasm itself. The HostEnsureCanCompileWasmBytes abstract operation is there to ensure that policies can be applied.
Note that there are no arguments to this abstract procedure - for good reason. However, that means that if you need a more detailed policy then that has to be a more refined way of handling resources on the CSP side.