SAFE_CSP_SOURCE regex rejects CSP keyword tokens ('unsafe-eval', 'wasm-unsafe-eval') in resourceDomains

[kboyce-cloud]

Which version line?

v2 — current (@modelcontextprotocol/inspector@latest)

Which client?

Web

Inspector version

2.2.0

Node version

v22.23.1

Operating system (and browser, for the web client)

windows, chrome

Transport

stdio

MCP server under inspection

own server via mcp sdk. modern protocol, using basic auth

The SAFE_CSP_SOURCE regex in clients/web/src/utils/sandbox-csp.ts rejects valid CSP keyword tokens like 'unsafe-eval' when declared in resourceDomains. This is a regression from v0.21.x where MCP Apps worked with 'unsafe-eval' in resourceDomains.

Steps to reproduce

1. Register an MCP Apps resource with _meta.csp.resourceDomains containing 'unsafe-eval' ```
   "_meta": {
   "csp": {
   "resourceDomains": ["http://localhost:8080", "'unsafe-eval'", "blob:", "data:"],
   "connectDomains": ["ws://localhost:8080", "http://localhost:8080"]
   }
   }

2. Open the app in Inspector v2.2.0's Apps tab
3. Console shows: [[mcp-app sandbox] dropping unsafe CSP source: 'unsafe-eval'](vscode-file://vscode-app/c:/Users/z00550zt/AppData/Local/Programs/Microsoft%20VS%20Code/df53daabb1/resources/app/out/vs/code/electron-browser/workbench/workbench.html)
4. App crashes with EvalError: Evaluating a string as JavaScript violates the following Content Security Policy directive

### Expected behavior

'unsafe-eval' should pass through approveCspSources and be included in the [script-src](vscode-file://vscode-app/c:/Users/z00550zt/AppData/Local/Programs/Microsoft%20VS%20Code/df53daabb1/resources/app/out/vs/code/electron-browser/workbench/workbench.html) directive, as it was in v0.21.x and as the MCP Apps spec (SEP-1865 §4) intends: ```
// From the spec's CSP construction example:
script-src 'self' 'unsafe-inline' ${csp?.resourceDomains?.join(' ') || ''};

The spec does not filter CSP keyword tokens from resourceDomains.

Root Cause
The SAFE_CSP_SOURCE regex requires the first character to be *, [a-zA-Z] (URL scheme), or [A-Za-z0-9] (hostname). A single quote ' doesn't match any alternative:

/^(?:\*|[a-zA-Z][a-zA-Z0-9+.-]*:...|(?:\*\.)?[A-Za-z0-9]...)$/
// 'unsafe-eval' starts with ' → no match → dropped

The approveCspSources comment says it screens for "injection safety" (preventing ;, ", <, > from breaking the CSP attribute). CSP keywords like 'unsafe-eval' don't contain injection characters and should be allowed.

Actual behavior

app crashed

Logs, errors, or screenshots

No response

Already prototyped a fix?

Add a pattern for CSP keyword tokens to the regex:

export const SAFE_CSP_SOURCE =
  /^(?:'[a-z][a-z0-9-]*'|\*|[a-zA-Z][a-zA-Z0-9+.-]*:(?:\/\/...)?|...)$/;
//    ^^^^^^^^^^^^^^^^^ new: matches 'unsafe-eval', 'wasm-unsafe-eval', etc.

Or use an explicit allowlist of known CSP keywords ('unsafe-eval', 'wasm-unsafe-eval', 'unsafe-hashes').

Before you submit

• I searched existing issues and this is not a duplicate.
• This is not a security vulnerability report (those go through the private advisory process).

[chiliec]

I've prepared a fix for this on a branch, but I can't open a PR against this repo — gh pr create returns chiliec does not have the correct permissions to execute CreatePullRequest, so I'm leaving the change here for a maintainer to pull in (or let me know if there's a contribution step I'm missing).

Branch/commit: chiliec@a78ba1a
(chiliec:fix/csp-keyword-tokens)

Fix: add a keyword alternative to SAFE_CSP_SOURCE — a single-quoted token of lowercase letters and hyphens only, '[a-z][a-z-]*':

-  /^(?:\*|[a-zA-Z][a-zA-Z0-9+.-]*:...
+  /^(?:'[a-z][a-z-]*'|\*|[a-zA-Z][a-zA-Z0-9+.-]*:...

The token carries no injection characters (;, ", <, >, whitespace), so it stays safe inside the CSP <meta> attribute — same "injection safety, not breadth" contract the surrounding code documents — while letting 'unsafe-eval', 'wasm-unsafe-eval', 'unsafe-hashes', and 'unsafe-inline' through. Hash/nonce keywords ('sha256-…', 'nonce-…') contain extra characters and are intentionally not matched.

Tests (extended sandbox-csp.test.ts): accept the four keywords above; reject injection attempts to prove safety is preserved ('unsafe-eval'; script-src *, '; script-src *', 'a"b', 'a<b', '', 'unsafe eval', 'UNSAFE-EVAL').

Verified locally (Node 22.19.0): vitest run --project=unit src/utils/sandbox-csp.test.ts → 43/43 pass; tsc --noEmit, eslint, and prettier all clean. RED→GREEN: reverting only the regex fails exactly the 4 new accept cases while every reject case still passes, confirming keyword support is added without weakening injection safety.

Happy to open a PR if permissions allow, or switch to an explicit allowlist ('unsafe-eval' / 'wasm-unsafe-eval' / 'unsafe-hashes') if you'd prefer to be stricter about which keywords pass.