How Chrome’s Site Isolation Stops Cross‑Tab Data Leaks

The problem: speculative side‑channel attacks across tabs

Modern browsers reuse a single renderer process for multiple tabs that belong to the same site. If malicious JavaScript runs in one tab, speculative execution attacks such as Spectre can potentially read memory belonging to another tab, even when the two pages have different origins. This cross‑origin leakage defeats the same‑origin policy that web developers rely on to keep data private.

How Site Isolation changes the process model

Chrome’s Site Isolation feature assigns a separate renderer process to each distinct effective top‑level domain plus scheme (e.g., https://example.com and https://example.org get their own processes). Tabs that share the same site still share a process, but any navigation to a different site forces a new renderer. This architectural split means that speculative side‑channels can no longer easily reach across site boundaries because the attacker’s code and the victim’s data live in different OS‑level memory spaces.

The feature has been enabled by default for most sites since Chrome 67 and can be forced for all sites via the flag #site-isolation-trial-opt-out (set to “Disabled”) or by enabling #site-isolation-per-origin.

Seeing Site Isolation in Chrome’s Task Manager

You can verify the isolation yourself with Chrome’s built‑in Task Manager.

1. Open Chrome and navigate to https://example.com in a tab.
2. Open a second tab and load https://example.org.
3. Press Shift+Esc (or visit chrome://processes) to open the Task Manager.
4. In the list, locate the entries labeled “Renderer”. You should see two separate renderer processes, each showing the site’s origin in the “Process ID” column (e.g., “example.com: 12345” and “example.org: 67890”).
5. Open a third tab to another page on example.com (e.g., https://example.com/other). The Task Manager will show that this tab shares the same renderer process as the first example.com tab, confirming same‑site sharing.

If you instead open two tabs to https://example.com and https://example.com (identical origin), you will see a single renderer process serving both tabs.

Trade‑offs, limitations and developer advice

Site Isolation improves security at a cost. Each extra renderer process consumes roughly the baseline memory of a tab, so enabling the feature can increase total RAM usage by 30‑100 % depending on how many distinct sites you have open. On low‑memory devices this may lead to slower overall browser performance or more frequent tab discarding.

Some extensions that rely on cross‑tab communication through shared renderer processes (e.g., certain password managers or developer tools) may break or require updates when Site Isolation is forced. Enterprise policies that alter process behavior should be tested in a staging environment before being rolled out.

Importantly, Site Isolation does not eliminate all side‑channel vectors. Attacks that rely on shared CPU caches, GPU processes, or other hardware resources still need complementary defenses such as Cross‑Origin‑Opener‑Policy (COOP) and Cross‑Origin‑Embedder‑Policy (COEP). Setting these response headers tells the browser to further isolate your site:

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

Developers should test their sites with Site Isolation enabled (the default for most users) and verify that any cross‑origin iframes, workers, or shared buffers continue to work as expected. Keeping Chrome up to date ensures you receive the latest refinements to the isolation logic and any performance improvements.

In practice, the verification steps above give you confidence that the feature is active. If you notice a significant jump in memory usage after opening cross‑site tabs, that is the expected trade‑off for the added protection against speculative data leaks.