MCP Server Content Security Policy Deep Dive: Nonce-Based Inline Scripts, strict-dynamic, and report-uri Monitoring for Browser-Based Agent UIs

Why MCP server browser UIs need a harder CSP than a typical web app

Most web application CSP guides start from the attacker model of a reflected or stored XSS that injects a <script> tag into the page. For MCP server browser UIs, the threat model is different and more severe:

1. Prompt injection via tool output — An attacker embeds instructions in a web page that your fetchPage tool retrieves. The LLM follows those instructions and includes attacker-controlled text in its response. If the UI renders LLM output as HTML, the attacker controls HTML in your authenticated UI.
2. Privileged context — The user is authenticated. The session has access to every tool the MCP server exposes. XSS in an MCP UI doesn't just steal a session cookie — it can call executeCode, readFile, sendEmail, or deleteRecord with the full permissions of the authenticated user, invisibly to them.
3. Rendered rich output — MCP tool outputs are increasingly rendered as markdown, HTML tables, or embedded previews. Every rendering pathway that doesn't treat tool output as untrusted text is a potential XSS sink.

Phase 1: Build the baseline from default-src 'none'

Most CSP guides recommend starting from a permissive policy and tightening it. For a new MCP server UI, start from default-src 'none' — a complete deny-all — and add back only what you actually need. This inverts the risk: you add explicit grants rather than hoping you've blocked all injection vectors.

Content-Security-Policy:
  default-src 'none';
  script-src 'self';
  style-src 'self';
  img-src 'self' data: https:;
  font-src 'self';
  connect-src 'self' wss://api.skillaudit.dev;
  frame-src 'none';
  object-src 'none';
  base-uri 'self';
  form-action 'self';
  frame-ancestors 'none';

This is the policy before nonces. It allows:

• script-src 'self' — only scripts loaded from your own origin; no inline scripts, no eval, no data URLs
• style-src 'self' — only stylesheets from your origin
• img-src 'self' data: https: — images from your origin, data URIs (for inline SVGs/favicons), and HTTPS sources (for tool output that includes images you can't pre-load)
• connect-src 'self' wss://api… — XHR/fetch to your API and WebSocket to your agent endpoint; adjust to your actual domains
• frame-src 'none' — no iframes at all yet; we'll add sandboxed iframes in Phase 3
• object-src 'none' — blocks Flash, Java applets, and all plugin content
• base-uri 'self' — prevents <base> tag injection, which can redirect all relative URLs to an attacker-controlled origin
• form-action 'self' — prevents form submissions being redirected to exfiltration endpoints
• frame-ancestors 'none' — prevents your MCP UI from being embedded in an attacker-controlled iframe (clickjacking defense; supersedes X-Frame-Options: DENY)

Phase 2: Add nonces for necessary inline scripts

Most MCP UIs need at least one inline script block — for bootstrapping configuration, setting up a WebSocket URL, or initializing a UI framework with data that must be available before the first network request. 'unsafe-inline' in script-src defeats the entire CSP and should never be used. The correct mechanism is a per-request cryptographic nonce.

How nonces work

The server generates a random nonce for every HTTP response. It includes that nonce in both the CSP header and the nonce attribute on allowed inline <script> tags. The browser only executes inline scripts whose nonce attribute matches the value in the CSP header — and since the nonce is random per request, an attacker who injects a <script> tag doesn't know the current request's nonce and cannot forge a matching attribute.

import crypto from 'node:crypto';

// Express middleware
function cspMiddleware(req, res, next) {
  // 128 bits of entropy, base64url-encoded
  const nonce = crypto.randomBytes(16).toString('base64url');

  // Attach to res.locals so templates can access it
  res.locals.cspNonce = nonce;

  // Build the CSP header string
  const csp = [
    "default-src 'none'",
    `script-src 'nonce-${nonce}' 'strict-dynamic'`,
    "style-src 'self'",
    "img-src 'self' data: https:",
    "font-src 'self'",
    `connect-src 'self' wss://${process.env.API_HOST}`,
    "frame-src 'none'",
    "object-src 'none'",
    "base-uri 'self'",
    "form-action 'self'",
    "frame-ancestors 'none'",
    `report-uri /csp-violations`,
  ].join('; ');

  res.setHeader('Content-Security-Policy', csp);
  next();
}

app.use(cspMiddleware);

In your HTML template, attach the nonce to every inline script:

<!-- EJS template -->
<script nonce="<%= cspNonce %>">
  window.__MCP_CONFIG__ = {
    wsUrl: '<%= wsUrl %>',
    userId: '<%= userId %>',
  };
</script>

<!-- Inline event handlers are NOT covered by nonces — they're always blocked -->
<!-- Wrong: <button onclick="doThing()">Click</button> -->
<!-- Right: addEventListener in your nonce-gated script block -->

Phase 3: strict-dynamic to handle dynamically loaded scripts

Modern MCP UIs use JavaScript frameworks that load additional scripts at runtime — React's lazy-loaded route chunks, Vite's dynamically split modules, or a third-party charting library loaded on demand. Without 'strict-dynamic', you'd need to add every CDN or bundle URL to your script-src allowlist — and an allowlist is exactly what attackers work to bypass via compromised CDN files or path traversal.

'strict-dynamic' changes the trust model: any script that was loaded via a nonce-bearing <script> tag is trusted to load further scripts. Trust propagates dynamically through the script loading chain, without requiring host-based allowlists.

# With strict-dynamic, this CSP header covers your bundled app AND all its dynamic imports:
Content-Security-Policy:
  script-src 'nonce-{REQUEST_NONCE}' 'strict-dynamic';
  ...

# Your HTML only needs the nonce on the entry-point script tag:
<script nonce="{REQUEST_NONCE}" src="/app.js" type="module"></script>
# app.js can dynamically import() other chunks — all covered by strict-dynamic propagation.

Phase 4: Sandboxed iframes for tool output rendering

Some MCP tools return rich content: HTML reports, data visualizations, embedded previews from external tools. Rendering this output directly in the main document context — even with DOMPurify sanitization — gives that content access to the main window's JavaScript context, storage, and network credentials. The safer pattern is rendering tool output in a sandboxed iframe.

function renderToolOutputSandboxed(htmlContent) {
  // Create a blob URL so the iframe has its own origin (null origin)
  const blob = new Blob([htmlContent], { type: 'text/html' });
  const blobUrl = URL.createObjectURL(blob);

  const iframe = document.createElement('iframe');

  // Maximum sandbox restrictions:
  // - No allow-scripts: no JavaScript execution in the tool output
  // - No allow-same-origin: the iframe gets null origin, preventing storage access
  // - allow-popups-to-escape-sandbox: if you need links to open, but omit if not
  iframe.setAttribute('sandbox', 'allow-popups allow-popups-to-escape-sandbox');

  // Additional security via the CSP attribute (CSP Level 3)
  iframe.setAttribute('csp', "default-src 'none'; style-src 'unsafe-inline'; img-src https: data:");

  iframe.setAttribute('loading', 'lazy');
  iframe.src = blobUrl;

  // Clean up blob URL after load to free memory
  iframe.addEventListener('load', () => URL.revokeObjectURL(blobUrl));

  return iframe;
}

// Update your main page CSP to allow blob: in frame-src:
// frame-src blob: 'none';  (blob: for sandboxed tool output iframes only)

Phase 5: style-src hardening — eliminating CSS injection

CSS injection is a less obvious XSS vector but a real one. An attacker who can inject arbitrary CSS into a page can exfiltrate data using CSS selectors combined with background-image: url() (the CSS exfiltration attack), overlay phishing content over the UI using position: fixed, or redirect form inputs. The style-src directive controls which stylesheets and inline styles are permitted.

# Ideal: no inline styles at all — all styles in external files
Content-Security-Policy: style-src 'self';

# If your framework injects inline style attributes (e.g. CSS-in-JS):
# Use nonces on style blocks the same way you use them on scripts
Content-Security-Policy: style-src 'self' 'nonce-{REQUEST_NONCE}';

# If you absolutely cannot avoid unsafe-inline for styles (legacy app):
# At minimum, block script-src unsafe-inline — CSS injection is lower risk than script injection
# But note: CSS-based attribute exfiltration still works with unsafe-inline styles
Content-Security-Policy: style-src 'self' 'unsafe-inline';

Phase 6: upgrade-insecure-requests and mixed content

If your MCP UI is served over HTTPS but any resource it loads — scripts, images, API calls — is fetched over HTTP, the browser will warn about mixed content and may block the request. The upgrade-insecure-requests CSP directive instructs the browser to automatically upgrade HTTP subresource requests to HTTPS before making them. It does not affect navigation (clicking links), only passive and active mixed content.

Content-Security-Policy:
  ...
  upgrade-insecure-requests;

This is a belt-and-suspenders directive. Your actual defense is ensuring all resources are served over HTTPS. upgrade-insecure-requests catches misconfigured hardcoded http:// URLs in your own templates that your developers missed.

Phase 7: report-uri and report-to — detecting bypasses in production

A CSP header with no reporting is silent on violations. You don't know if attackers are attempting injections, if your policy is blocking legitimate functionality you missed in testing, or if a third-party script your CDN serves has been compromised and is being blocked. The report-uri and report-to directives instruct the browser to POST a JSON violation report to an endpoint you control.

// Add to your CSP header:
// report-uri /csp-violations
// report-to csp-endpoint

// The newer Reporting API header (for report-to):
// Report-To: {"group":"csp-endpoint","max_age":86400,"endpoints":[{"url":"/csp-violations"}]}

// Express endpoint:
app.post('/csp-violations', express.json({ type: 'application/csp-report' }), (req, res) => {
  const report = req.body['csp-report'];
  if (!report) return res.status(400).end();

  // Log to your observability stack — violations are noisy, aggregate them
  logger.warn('CSP violation', {
    blockedUri: report['blocked-uri'],
    violatedDirective: report['violated-directive'],
    originalPolicy: report['original-policy'],
    documentUri: report['document-uri'],
    referrer: report['referrer'],
    // Never log the full source-file or script-sample in production without PII scrubbing
  });

  res.status(204).end();
});

// Rate-limit this endpoint — browsers retry violations,
// and an attacker can trigger thousands of reports as a DoS vector
app.use('/csp-violations', rateLimit({ windowMs: 60_000, max: 100 }));

What CSP violation reports reveal

The complete production CSP for an MCP server browser UI

Putting all phases together, this is the production policy served on authenticated MCP UI pages:

Content-Security-Policy:
  default-src 'none';
  script-src 'nonce-{REQUEST_NONCE}' 'strict-dynamic' 'unsafe-inline';
  style-src 'self' 'nonce-{REQUEST_NONCE}';
  img-src 'self' data: https:;
  font-src 'self';
  connect-src 'self' wss://api.yourdomain.com;
  frame-src blob:;
  object-src 'none';
  base-uri 'self';
  form-action 'self';
  frame-ancestors 'none';
  upgrade-insecure-requests;
  report-uri /csp-violations;

Notes on this policy:

• 'unsafe-inline' in script-src is ignored by browsers that support nonces (CSP Level 2+), so it only affects very old browsers as a fallback
• frame-src blob: allows the sandboxed tool output iframes from Phase 4 (blob URLs); 'none' would block them
• wss://api.yourdomain.com allows your WebSocket agent connection; adjust to your actual API domain
• {REQUEST_NONCE} is replaced by your middleware with a fresh crypto.randomBytes(16).toString('base64url') value on every response

Common MCP server CSP mistakes

CSP deployment checklist for MCP server UIs

• Deploy as Content-Security-Policy-Report-Only first and observe violations for one week before switching to enforcement
• Generate nonces with crypto.randomBytes(16).toString('base64url') per HTTP response — never reuse nonces
• Set Cache-Control: no-store on all responses that include nonces — cached nonces are reusable by attackers
• Include 'strict-dynamic' in script-src to eliminate CDN host allowlists
• Set frame-ancestors 'none' to prevent clickjacking of MCP tool actions
• Render tool output HTML in sandboxed iframes using blob URLs (no allow-same-origin in sandbox)
• Set object-src 'none' and base-uri 'self' — these are not covered by default-src
• Add report-uri /csp-violations with rate limiting on the collection endpoint
• Wire CSP violation logs into your alerting — a spike in script-src inline violations is an active attack signal
• If using CSS-in-JS, configure the library to accept a nonce value via its server-side rendering API
• Test your policy with Google's CSP Evaluator before shipping

SkillAudit findings for CSP in MCP servers

Summary

Content Security Policy for browser-based MCP server UIs needs to be more rigorous than for a standard web app, because XSS in an MCP UI gives the attacker the full capability surface of every tool the authenticated user can call. The effective defense is a layered policy built in phases: start from default-src 'none', add per-request nonces for any necessary inline scripts, use 'strict-dynamic' to propagate trust through dynamic imports without CDN host allowlists, render all tool output HTML in maximally sandboxed iframes, block framing with frame-ancestors 'none', and instrument everything with report-uri to surface active attacks in production.

The mistake that ends careers in MCP security is shipping an authenticated UI with 'unsafe-inline' in script-src because it was the path of least resistance during development. A nonce-based policy with strict-dynamic is not significantly harder to build — it just requires the nonce middleware and a template change. The security gain is closing the entire inline-script injection surface permanently, which is the single most impactful CSP change you can make.

SkillAudit checks for missing or misconfigured CSP headers, unsafe-inline directives, static nonces, and missing frame-ancestors as part of every audit. See a sample audit report or run a free audit on your MCP server.