Security Model

Last updated: June 1, 2026

WebSandbox's multi-layered security model — browser sandbox, WASM isolation, Service Worker scoping, and data privacy.

Security Overview

WebSandbox provides three distinct isolation layers:

• Browser sandbox — the outermost layer, enforced by the browser's process model and same-origin policy
• Runtime isolation — the WebContainer WASM sandbox for Instant Projects, or secure multi-tenant VMs/containers for Cloud Servers, preventing code from escaping to the host OS
• Service Worker scoping — prevents preview traffic from one workspace leaking into another

Browser Sandbox Layer

All WebSandbox code runs inside the browser's renderer process. The browser enforces:

• Same-origin policy — the workspace origin cannot access resources from other origins without explicit CORS headers
• Content Security Policy (CSP) — WebSandbox sets a strict CSP that disallows inline scripts outside the controlled execution context
• COOP/COEP isolation headers — WebSandbox sets both Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp to enable SharedArrayBuffer without cross-origin leaks

Runtime Isolation (WASM & VMs)

For Instant Projects, the WebContainer runtime executes inside a WASM module with a strictly limited syscall interface. Code running inside the WebContainer:

• Cannot access the host file system — only the virtual FS exposed by the WebContainer API
• Cannot spawn native processes on the host OS
• Cannot access hardware interfaces (GPU, camera, microphone) unless explicitly granted by the browser
• Cannot read browser cookies, localStorage, or IndexedDB data from other origins

A compromised npm package running inside a WebSandbox workspace cannot exfiltrate data from other browser tabs or your local file system.

For Cloud Servers, execution happens in highly isolated cloud environments. Workspaces run in unprivileged containers or dedicated VMs with no access to underlying platform credentials or other tenants' data.

Service Worker Scoping

Each workspace's preview traffic is routed through a Service Worker that is scoped to a unique origin (https://<workspace-id>.local.websandbox.dev). This means:

• Workspace A cannot make requests to Workspace B's dev server — the Service Worker origins are different
• A malicious script in one workspace cannot intercept or modify preview traffic from another workspace
• Service Worker registrations are cleared when a workspace is deleted

Data Storage & Privacy

For Instant Projects, workspace files are stored in your browser's IndexedDB. For Cloud Servers, files are stored on isolated, encrypted cloud volumes. They never leave your workspace environment unless you:

• Push to a git remote
• Export a ZIP and upload it somewhere

WebSandbox engineers do not have direct access to your workspace files. Our backend stores workspace metadata (name, timestamps, plan limits). Cloud Server volumes are encrypted at rest and isolated by tenant.

Network Security

All communication between your browser and the WebSandbox backend is over TLS (HTTPS). API authentication uses short-lived JWT tokens issued at login. Tokens are stored in memory (not localStorage or cookies) to reduce XSS attack surface.

git authentication tokens (Personal Access Tokens) are stored encrypted server-side and are only decrypted at the point of use within the git operation request lifecycle.

Vulnerability Reporting

If you discover a security vulnerability in WebSandbox, please report it responsibly via email: security@websandbox.online with the subject line [SECURITY]. We aim to acknowledge all reports within 24 hours and resolve critical issues within 72 hours.

Please do not disclose security issues publicly until we have had a reasonable opportunity to investigate and address them.