Repository navigation
Support wasm-unsafe-eval CSP directive to enable WebAssembly in MCP Apps #605
Description
Problem
WebAssembly-based frameworks (Blazor, Uno Platform, Rust/Wasm, Go/Wasm, Pyodide, etc.) cannot run inside MCP App iframes because the current CSP does not include wasm-unsafe-eval in script-src.
When a Wasm module calls WebAssembly.compileStreaming() or WebAssembly.instantiate(), the browser blocks it:
Refused to compile or instantiate WebAssembly module because 'unsafe-eval' is not an
allowed source of script in the following Content Security Policy directive: "script-src ..."
Why wasm-unsafe-eval and not unsafe-eval
The wasm-unsafe-eval directive was introduced specifically to decouple WebAssembly compilation from JavaScript eval(). It:
- Allows
WebAssembly.compile(),WebAssembly.instantiate(), andWebAssembly.compileStreaming() - Does not allow
eval(),new Function(), or other dynamic JS code generation - Is supported in all major browsers (Chrome 97+, Firefox 102+, Safari 16+)
- Is the recommended approach for enabling Wasm under CSP
This is significantly safer than unsafe-eval and addresses a different set of use cases.
Affected frameworks
Any framework that compiles to WebAssembly is blocked:
| Framework | Language | Use case |
|---|---|---|
| Blazor WebAssembly | C#/.NET | Full-stack .NET web apps |
| Uno Platform (Wasm) | C#/.NET | Cross-platform XAML apps |
| Pyodide | Python | Data science, notebooks |
| Rust/wasm-bindgen | Rust | Performance-critical components |
| Go (GOOS=js) | Go | Portable Go applications |
| AssemblyScript | TypeScript-like | Wasm-first development |
Proposal
Add a wasmUnsafeEval boolean (or a scriptPolicies array) to the CSP metadata that servers can declare:
{
"_meta": {
"ui": {
"csp": {
"resourceDomains": ["http://localhost:5173/"],
"connectDomains": ["http://localhost:5173/"],
"wasmUnsafeEval": true
}
}
}
}Hosts that support it would add 'wasm-unsafe-eval' to the script-src directive of the iframe's CSP. Hosts that don't support it can safely ignore the field (Wasm simply won't load, which is the current behavior).
Related issues
- threejs-server example cannot work within current spec due to
unsafe-eval#199 —unsafe-evalneeded for three.js (broader, includes JS eval) - [Proposal] Features for speeding up slow Python/ Pyodide based apps #513 — Pyodide/Wasm performance in Claude.ai (related but focused on COOP/COEP headers)
- SEP: Sandbox capabilities #58 — Sandbox capabilities negotiation (meta-issue)
Activity
idosal commentedon May 5, 2026
Makes sense. Curious to hear if Hosts have any particular concerns around this (@aharvard @ochafik @connor4312 @infoxicator)
connor4312 commentedon May 5, 2026
I think it would reasonable to add this by default. WASM isn't "XSS-y" by itself, which is the reason we don't have trusted types for WASM w3c/trusted-types#256 (comment)
wasm-unsafe-evalis never less safe. Pages need it to run WASM. And if the page doesn't have code that runs WASM, an XSS is needed to run it in the first place, so an attacker could just run JS instead.idosal commentedon May 5, 2026
Sounds good to me. We can bring it up in tomorrow's WG meeting just to get a feel from the room.
vahagnv commentedon Aug 8, 2026
Hi Ido. I wonder if there are plans to merge the wasm support?
omarkawach commentedon Aug 20, 2026
The latest release of VS Code introduced MCP Apps support. I was trying to render an MCP App iframe in chat with a library I use often and was unable to do so because i can't set
wasm-unsafe-eval.kisg commentedon Sep 14, 2026
We are also interested in using wasm-unsafe-eval to be able to render WebGL content with a WASM library. Is there any way we can help moving this process along? I did not see any objections in the discussions here or in the WG meeting minutes. Would it be possible to add this topic to the next WG meeting and discuss it there?