How We Keep Your Code Safe: The WebSandbox Security Model

The first question most enterprise and security-conscious developers ask when they see WebSandbox is: "You're running my code in the browser — is that safe?" It's the right question to ask, especially for a proprietary platform handling sensitive code.

The answer is yes — and here's why, explained layer by layer. Security at WebSandbox is not a single mechanism but a defence-in-depth stack where each layer independently limits what malicious or buggy user code can do.

Layer 1: The Browser Sandbox

WebContainers run entirely within the browser's security sandbox. Your code cannot access the host operating system, the real filesystem, or other browser tabs. This is enforced by the browser itself — not by us — which means it's as robust as Chrome's or Firefox's process isolation.

The WASM runtime that powers our WebContainer instance does not have access to Atomics.wait, raw system calls, or the host network stack. All of those are virtualized within the container securely.

Layer 2: Origin Isolation

In our proprietary Next.js configuration (next.config.js), we strictly enforce Cross-Origin-Opener-Policy: same-origin, Cross-Origin-Embedder-Policy: require-corp, and Cross-Origin-Resource-Policy: cross-origin headers. These are absolutely required to enable SharedArrayBuffer, which the WASM runtime relies on for high-performance memory sharing. We specifically use require-corp instead of credentialless because Safari does not yet fully support credentialless. This ensures cross-origin isolation works flawlessly on Safari 17+ and enterprise browsers.

This means a malicious workspace cannot use speculative execution attacks like Spectre to read memory from another workspace's origin. Each workspace runs in its own browsing context with its own JavaScript heap.

Layer 3: The Preview Iframe Sandbox

Our CSP headers restrict which scripts, styles, and network requests the application can make, significantly reducing the attack surface for XSS attacks.

The preview-panel.tsx component — where user-authored code actually renders — sits inside a strictly sandboxed iframe. Crucially, we set allow="cross-origin-isolated" on this iframe. This carefully bridges the WebContainer's dev server output to the UI without leaking capabilities to the parent window. It has a completely separate CSP that further restricts what it can do:

• No access to localStorage or sessionStorage of the parent origin.
• No ability to navigate the top-level frame.
• No access to the Clipboard API without explicit user gesture.

Layer 4: Network Controls

The WebContainer's networking layer is virtualized. Code running inside a workspace can reach the internet via standard fetch and WebSocket APIs, but all traffic is proxied through our custom edge layer which applies strict rate limiting and enterprise-grade abuse detection.

Workspaces cannot reach internal network addresses (10.x.x.x, 172.16.x.x, 192.168.x.x) or the link-local address space, preventing SSRF-style attacks against services running on the user's local network.