Architecting for Chrome Site Isolation: Trust Boundaries and Process Separation

The Problem: Renderer Compromise

In a modern browser, the renderer process is the most exposed surface area. It parses untrusted HTML, executes third-party JavaScript, and handles complex CSS. If an attacker achieves remote code execution (RCE) within a renderer, they can potentially read any memory resident in that process. Without process isolation, a single renderer hosting multiple tabs or iframes from different domains would allow an attacker to steal session tokens or read sensitive data from a neighboring site.

The Takeaway: Chrome Site Isolation ensures that documents from different sites (eTLD+1) are hosted in separate renderer processes. While this provides a powerful defense-in-depth layer against memory-scraping attacks (like Spectre), it is not a substitute for server-side authorization or secure cookie attributes.

Requirements for Process Isolation

To rely on Site Isolation for a security boundary, the environment must meet specific criteria. By default, desktop Chrome (v67+) enables site-per-process. However, the following conditions must be verified:

• Platform: Desktop environments provide the most consistent isolation. Mobile platforms (Android) may implement partial isolation based on available RAM or whether the site contains passwords.
• Memory Availability: Chrome may group processes or reduce isolation levels if the system is under extreme memory pressure.
• Enterprise Policy: Managed environments may have SitePerProcess or IsolateOrigins policies configured. If these are disabled via GPO or Chrome Enterprise, the isolation guarantees are voided.

The Smallest Suitable Design

When designing a high-security web application, treat Site Isolation as a secondary boundary. The smallest viable security architecture follows these tiers:

1. Primary Control: Implement strict server-side authorization and CSRF protections. Never assume the client-side process is secure.
2. Credential Scoping: Use SameSite=Lax or Strict and HttpOnly flags on cookies to prevent cross-site leakage regardless of process boundaries.
3. Origin-Level Isolation: For high-value pages (e.g., payment gateways), move beyond site-level isolation to origin-level isolation. This is achieved by sending the following HTTP response headers:

   Cross-Origin-Opener-Policy: same-origin
   Cross-Origin-Embedder-Policy: require-corp

   This forces the browser to isolate the document into its own process, even from other origins on the same site.
4. Content Minimization: Avoid embedding untrusted third-party iframes within privileged pages. If necessary, ensure they are cross-site so they are forced into separate renderers.

Trust and Data Boundaries

It is critical to distinguish between the Renderer Process and the Browser Process.

Boundary	Scope	Trust Level	Responsibility
Renderer Process	Single Site / Origin	Untrusted	DOM parsing, JS execution, Rendering
Browser Process	Entire Browser Instance	Trusted	Network stack, Storage, OS IPC, Window management

The actual security boundary is the Chrome Sandbox. The renderer process cannot access the filesystem or network directly; it must request these actions from the Browser Process via Inter-Process Communication (IPC). Site Isolation adds a horizontal boundary: it prevents Renderer A from reading the memory of Renderer B.

Operational Verification

To verify that your sensitive page and its embedded third-party content are actually isolated, use these diagnostic tools in desktop Chrome:

1. Process Internals

Navigate to chrome://process-internals. Search for your page URL. Check the Process ID (PID) assigned to the main frame and compare it to the PID assigned to any cross-site iframes. If the PIDs differ, they are isolated.

2. Chrome Task Manager

Press Shift + Esc. This lists every active renderer process. If you have a page with a third-party iframe, you should see two separate "Tab: [Page Name]" or "Subframe: [URL]" entries with distinct memory footprints.

3. Sandbox Status

Navigate to chrome://sandbox to ensure the sandbox is active. If the sandbox is disabled (via --no-sandbox flag), Site Isolation is effectively neutralized because a compromised renderer can bypass process boundaries via OS-level calls.

Failure Modes and Design Shifts

The following conditions indicate that your design must shift from relying on browser isolation to stricter server-side or architectural controls:

• Low-RAM Targets: If your user base primarily uses low-end Android devices, assume partial site isolation. You cannot rely on process separation for security.
• Sandbox Escapes: If your threat model includes attackers capable of "sandbox escapes" (exploiting the Browser Process or Kernel), process isolation is irrelevant. In this case, use Content-Security-Policy (CSP) to limit the attack surface.
• IPC Latency: Heavy reliance on cross-process communication for complex iframes can introduce latency. If performance degrades, you may be tempted to force same-process loading; do not do this for sensitive data. Instead, redesign the data flow to use postMessage across isolated boundaries.