modelcontextprotocol / modelcontextprotocol/ext-apps

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

Open
#605 6 comments 6 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
2.9k
Forks
387
Avg merge
3h 21m
Merged PRs (30d)
6

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(), 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

  • #199 — unsafe-eval needed for three.js (broader, includes JS eval)
  • #513 — Pyodide/Wasm performance in Claude.ai (related but focused on COOP/COEP headers)
  • #58 — Sandbox capabilities negotiation (meta-issue)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the _meta.ui.csp metadata path and the iframe CSP script-src generation; inspect how resourceDomains and connectDomains are declared and applied. Done when a host can declare the Wasm opt-in, supported hosts emit 'wasm-unsafe-eval', unsupported hosts ignore it, and the behavior is covered by the repository's existing checks.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript, wasm
Domain
api, security
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.