The WASM Sandbox.

What is the Browser Sandbox?

Modern web browsers implement a comprehensive security model called the "sandbox" that isolates web content from the underlying operating system. This sandbox prevents malicious websites from accessing files, executing arbitrary code, or compromising system security.

WebAssembly (WASM) executes within this same sandbox, meaning code compiled to WASM has the same security restrictions as regular JavaScript. However, WASM provides a performance advantage—near-native execution speed—while maintaining the same security guarantees.

Security Boundaries

The browser sandbox enforces multiple layers of protection:

• Memory Isolation: WASM modules run in a linear memory space that is separate from the browser's own memory. This prevents WASM code from reading or modifying browser internals.
• No Direct File Access: Web content cannot directly access the file system. Files can only be accessed through explicit user actions (like selecting a file via an input element).
• No Network Control: WASM code cannot initiate arbitrary network requests. All network calls go through the browser's fetch API, which enforces CORS and other security policies.
• No System APIs: WASM cannot access operating system APIs like processes, sockets, or hardware devices.

File Processing in the Sandbox

When you select a PDF file in DocuStitch, the browser provides the file to the JavaScript/WASM code as a File object. This object represents the file's contents in memory, but does not provide a path or direct access to the underlying file system.

Our WASM PDF engine reads the file's bytes from this memory object, performs operations entirely within the WASM linear memory, and produces a result as a new memory buffer. The browser then provides this result to the user for download. Throughout this process:

• The file never touches the disk except during the explicit download
• Network requests are never made to external servers
• The file contents are never exposed to JavaScript outside the WASM module

Same-Origin Policy

The Same-Origin Policy (SOP) is a critical browser security mechanism that restricts how documents or scripts loaded from one origin can interact with resources from another origin. In the context of WASM:

• WASM modules inherit the origin of the page that loaded them
• Cross-origin requests require explicit CORS headers
• WASM cannot bypass SOP restrictions

This means that even if a malicious actor compromised the WASM code, they would still be bound by the same origin restrictions as any other web content.

Content Security Policy

Content Security Policy (CSP) is an additional layer of defense that helps detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. DocuStitch implements strict CSP headers:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'wasm-unsafe-eval';
  img-src 'self' data:;
  connect-src 'self';
  frame-src 'none';
  object-src 'none';

The 'wasm-unsafe-eval' directive allows WASM execution while still maintaining other security restrictions.

Common Misconceptions

Verification Steps

You can verify DocuStitch's security model yourself:

1. Open the browser's Network tab in Developer Tools
2. Load a PDF and process it
3. Observe that no network requests are made during processing
4. Disable your internet connection after the page loads
5. Continue processing files—everything still works

Enterprise Considerations

For enterprise deployments, browser sandboxing provides several advantages:

• No data egress: Documents never leave the corporate network
• No third-party risk: No dependency on external service providers
• Auditability: Browser behavior can be monitored and logged
• Compliance: Local processing satisfies data residency requirements