MCP server Origin Private File System security — no-permission persistent storage, cross-tab access, and storage-clear evasion

What OPFS provides and why it requires no permission

The Origin Private File System is part of the File System Access API specification (distinct from the user-facing file picker API). While showOpenFilePicker() and showSaveFilePicker() require explicit user consent because they access the host OS filesystem, OPFS is sandboxed entirely within the browser's origin partition and is treated as a managed storage resource — similar to IndexedDB or Cache Storage — that does not require a user permission gate.

Any same-origin JavaScript can call await navigator.storage.getDirectory() to obtain the root FileSystemDirectoryHandle and from there read, write, create, and delete files without any prompt. Browser quota applies (typically up to 60% of available disk space), but no per-access permission is required. This is architecturally intentional: OPFS is meant for high-performance application storage (SQLite WASM databases, large asset caches, offline editor state), not for user-visible files.

// OPFS access — no permission prompt required
const root = await navigator.storage.getDirectory();

// Create or open a file in OPFS
const fileHandle = await root.getFileHandle('staged-payload.json', { create: true });
const writable = await fileHandle.createWritable();

// Write stolen data — this call is asynchronous (main thread)
const stolen = {
  cookies: document.cookie,
  storage: { ...localStorage },
  url: location.href,
  timestamp: Date.now()
};
await writable.write(JSON.stringify(stolen));
await writable.close();
// File is now persisted in OPFS — survives page reload, localStorage.clear(), cookies.clear()

OPFS AccessHandles in Web Workers: synchronous, high-throughput writes

The OPFS specification includes a Web Worker-only API: FileSystemFileHandle.createSyncAccessHandle(). In a dedicated or shared worker context, this returns a synchronous access handle that allows accessHandle.write(buffer, { at: offset }) calls without any Promise overhead. This is the fastest possible file write path in the browser — used by SQLite WASM for its WAL implementation.

For MCP tool output attackers, this matters because: (1) if the injection can spawn a worker (or reach an existing one), synchronous OPFS writes enable high-throughput staging of large data volumes before the user's tab becomes unresponsive; (2) the synchronous nature means the entire staging operation can complete in a single worker turn, reducing the time window in which CPU profiling tools might observe the work.

// In an injected Web Worker — synchronous OPFS write
// worker.js (injected or reached via postMessage)
const root = await navigator.storage.getDirectory();
const fileHandle = await root.getFileHandle('sync-payload.bin', { create: true });

// createSyncAccessHandle() is only available in dedicated/shared workers
const accessHandle = await fileHandle.createSyncAccessHandle();

// Synchronous write — no Promise overhead
const encoder = new TextEncoder();
const buffer = encoder.encode(JSON.stringify(largePayload));
accessHandle.write(buffer, { at: 0 });
accessHandle.flush();
accessHandle.close();
// Write completes synchronously — no async gaps, minimal CPU profile exposure

Cross-tab data access via shared OPFS scope

All tabs and workers at the same origin share the same OPFS namespace. A file written to OPFS in one tab is immediately readable from another tab at the same origin. For MCP deployments where a user opens multiple tool sessions or switches between chat windows at the same origin, an OPFS file written in one session is accessible in all concurrent sessions. An injection that writes to OPFS in a low-privilege session (e.g., a tab with restricted tool access) can have its data read by a higher-privilege session at the same origin.

Permissions-Policy gap and defenses

As of mid-2026, there is no Permissions-Policy feature name for OPFS. Unlike the user-facing File System Access API (which has file-system in the policy), OPFS is not gated by a Permissions-Policy directive. The primary defenses are architectural:

Cross-origin sandboxed iframe — if MCP tool output is rendered in a sandboxed iframe at a distinct registrable domain (not a subdomain of the main application), the iframe has its own OPFS partition and cannot read or write the application's OPFS. The sandbox attribute on iframes restricts storage access; allow-same-origin must not be combined with allow-scripts on same-origin iframes or the sandbox is bypassed.

CSP script-src nonce — prevents the script injection that would reach navigator.storage.getDirectory() in the first place. Without script execution, OPFS is not accessible.

SkillAudit findings for OPFS exposure