Support `wasm-unsafe-eval` CSP directive to enable WebAssembly in MCP Apps

[carldebilly]

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(), and WebAssembly.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-eval needed 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)