How Chromium's Site Isolation Protects Your Sensitive Data

This article explores Site Isolation, a critical security architecture in the Chromium web browser designed to protect sensitive user data from sophisticated cyber threats. By fundamentally changing how the browser handles websites, Site Isolation ensures that pages from different domains are always placed into separate operating system processes. Specifically, it isolates cross-site iframes into their own dedicated processes, preventing malicious code on one site from stealing data from another, even in the presence of hardware vulnerabilities and renderer bugs.

The Vulnerability of Shared Memory

To understand Site Isolation, it is first necessary to understand how browsers functioned before its implementation. Historically, Chromium used a multi-process architecture that generally assigned one renderer process per browser tab. While this kept different tabs isolated from one another, a single webpage rarely consists of content from just one source. Websites frequently use iframes to embed cross-site content, such as advertisements, payment gateways, video players, and social media widgets.

Under the old model, the main webpage and all of its embedded cross-site iframes shared the exact same operating system process and, consequently, the same memory space. Browsers relied on the Same-Origin Policy—a software-level rule—to stop an iframe from accessing the main page's data. However, if an attacker exploited a bug in the renderer process or utilized a CPU side-channel attack like Spectre, they could bypass software rules and read the entire memory of that shared process. This meant a malicious ad iframe could potentially read sensitive data, such as passwords or session tokens, from the main page it was embedded on.

Out-of-Process Iframes (OOPIFs)

Site Isolation solves the shared-memory vulnerability by redefining the boundaries of a browser process. Instead of tying a process to a tab, Chromium now ties a process to a specific site (defined by its scheme and registered domain).

When a webpage loads an iframe from a different site, Chromium splits the tab into multiple processes using a technology called Out-of-Process Iframes (OOPIFs). The main webpage runs in one renderer process, and the cross-site iframe runs in a completely separate renderer process. To the user, the webpage looks completely normal because the main browser process seamlessly composites the visual output of both processes onto the screen. Under the hood, however, the two sites are strictly divorced.

OS-Level Memory Protection

By placing cross-site iframes into separate processes, Chromium offloads the burden of memory protection to the host operating system. Operating systems are fundamentally designed to prevent one process from reading or writing to the memory space of another process.

Consider a scenario where a user visits a malicious website that secretly embeds an iframe of a banking website where the user is currently logged in. Without Site Isolation, both sites exist in the same memory space, putting the banking data at risk of a Spectre attack. With Site Isolation, the banking iframe is placed in its own isolated process. Even if the malicious website successfully executes a speculative execution attack to read every single byte of memory in its own process, the banking data is simply not there to be stolen. It resides safely in a different process that the attacker cannot reach.

Filtering Data with Cross-Origin Read Blocking

Separating iframes into different processes is only fully effective if a compromised process cannot simply request sensitive cross-site data over the network. Because websites are legitimately allowed to request certain cross-origin resources (like images and scripts), a compromised process might try to trick the browser into fetching sensitive cross-site HTML, XML, or JSON data and loading it into its memory as if it were an image.

To prevent this, Site Isolation relies on a defense mechanism called Cross-Origin Read Blocking (CORB). All network requests are routed through Chromium's central, privileged browser process before reaching any renderer process. CORB inspects the data returning from the network. If a process running a cross-site iframe requests data from another origin, and that data turns out to be sensitive (like a JSON file containing user credentials) rather than a permissible file type (like a JPEG image), the browser process blocks the data. It is stripped out before it ever enters the memory of the untrusted renderer process, ensuring the isolation boundary remains absolute.