the Chromium logo

The Chromium Projects
Chromium > Chromium Security >

Site Isolation

Overview

Site Isolation is a security feature in Chrome that offers additional protection against some types of security bugs. It uses Chrome's sandbox to make it harder for untrustworthy websites to access or steal information from your accounts on other websites.

Websites are typically not allowed to access each other's data inside the browser, thanks to code that enforces the Same Origin Policy. Occasionally, security bugs are found in this code and malicious websites may try to bypass these rules to attack other websites. The Chrome team aims to fix such bugs as quickly as possible.

Site Isolation offers an extra line of defense to make such attacks less likely to succeed. It ensures that pages from different websites are always put into different processes, each running in a sandbox that limits what the process is allowed to do. It also makes it possible to block the process from receiving most types of sensitive data from other sites. As a result, a malicious website will find it much more difficult to steal data from other sites, even if it can break some of the rules in its own process.

This protection is made possible by the following changes in Chrome's behavior:

Here, we use a precise definition for a site: the scheme and registered domain name, including the public suffix, but ignoring subdomains, port, or path. For example, an origin like https://foo.example.com:8080 would have a site of https://example.com. We use sites instead of origins to avoid breaking compatibility with existing web pages that might modify their document.domain to communicate across multiple subdomains of a site.

For more technical information about the protections offered by Site Isolation and how they are built, please see the project's design document.

Motivation

Web browser security is important: browsers must defend against untrustworthy web pages that try to attack other sites or access the user's machine. Given the complexity of the browser, it is necessary to use a "defense in depth" approach to limit the damage that occurs even if an attacker finds a way around the Same Origin Policy or other security logic in the browser. As a result, Chrome uses a sandbox and Site Isolation to try to defend against even powerful attackers (e.g., who might know about bugs in the browser). This is motivated by several different types of attacks.

First, compromised renderer processes (also known as "arbitrary code execution" attacks in the renderer process) need to be explicitly included in a browser’s security threat model. We assume that determined attackers will be able to find a way to compromise a renderer process, for several reasons:

Second, universal cross-site scripting (UXSS) bugs pose a similar threat. Security bugs of this form would normally let an attacker bypass the Same Origin Policy within the renderer process, though they don't give the attacker complete control over the process. Such UXSS bugs tend to be common.

Third, side channel attacks such as Spectre make reading arbitrary renderer process memory possible, even without bugs in Chrome. This poses additional risks to sensitive data in the renderer process, and it can make exploitation easier.

Chrome's architecture provides additional defenses against these powerful attacks. Chrome's sandbox helps prevent a compromised renderer process from being able to access arbitrary local resources (e.g. files, devices). Site Isolation helps protect websites against attacks from compromised renderer processes, UXSS, and side-channel attacks like Spectre.

For more background and motivation, see our Usenix Security 2019 conference paper on Site Isolation, and Chrome's Post-Spectre Threat Model Re-Think.

Current Status

Desktop Platforms

Site Isolation was enabled by default for all sites in Chrome 67 on Windows, Mac, Linux, and Chrome OS to help to defend against attacks that are able to read otherwise inaccessible data within a process, such as speculative side-channel attack techniques like Spectre/Meltdown. As of Chrome 77, Site Isolation also now defends against fully compromised renderer processes and UXSS bugs on desktop platforms. In M92, Site Isolation expanded to isolate all extensions from each other as well. In M110, Site Isolation support was added for <webview> tags.

Android

On Android devices with at least 2 GB of RAM, Site Isolation has been enabled for sites that users log into since Chrome 77. In Chrome 92, this expanded to include sites that use third-party login providers (e.g., OAuth) and sites that adopt Cross-Origin-Opener-Policy headers.

Limitations

Tradeoffs

Site Isolation represents a major architecture change for Chrome, so there are some tradeoffs when enabling it, such as increased memory overhead. The team has worked hard to minimize this overhead and fix as many functional issues as possible. A few known issues remain:

For users:

For web developers:

How to Configure

For most users, no action is required, and Site Isolation is enabled at an appropriate level based on available resources.

For more advanced cases, it is possible to isolate additional sites and origins in a few ways. Note that changes to chrome://flags and the command line only affect the current device, and are not synced to your other instances of Chrome.

1) Isolating All Sites (Android)

This mode is already enabled by default for 100% of Chrome users on Windows, Mac, Linux, and Chrome OS. The instructions below can still be useful on Android, for users desiring the highest security on devices with sufficient RAM.

This mode ensures that all sites are put into dedicated processes that are not shared with other sites. It can be enabled in either of the following ways:

2) Isolating Specific Origins

This mode allows you to provide a list of specific origins that will be given dedicated processes. On desktop platforms where Site Isolation is already fully enabled, these origins will be isolated at a finer granularity than their site (e.g., https://foo.example.com can be isolated from the rest of https://example.com). On Android, these origins will be isolated in addition to any other sites already isolated. This can be used to isolate any origins that need extra protection, such as any that you log into. (Note that wildcards are supported to isolate all origins underneath a given origin.)

This mode is automatically enabled on Android devices with at least 2 GB of memory as of Chrome 77, for sites that users log into. This mode can be further manually configured in any of the following ways:

3) Isolating All Origins

This mode is experimental and will break any pages that depend on modifying document.domain to access a cross-origin but same-site page. It will also increase Chrome's process count and may affect performance. The benefit is that every origin will require its own dedicated process, such that two origins from the same site won't share a process.

This mode can be configured by enabling chrome://flags#strict-origin-isolation

Diagnosing Issues

If you encounter problems when Site Isolation is enabled, you can try turning it off by undoing the steps above, to see if the problem goes away.

You can also try opting out of field trials of Site Isolation to diagnose bugs, by visiting chrome://flags#site-isolation-trial-opt-out, choosing "Disabled (not recommended)," and restarting.

Starting Chrome with the --disable-site-isolation-trials flag is equivalent to the opt-out above.

Note that if Site Isolation has been enabled by enterprise policy, then none of these options can be used to disable it.

We encourage you to file bugs if you encounter problems when using Site Isolation that go away when disabling it. In the bug report, please describe the problem and mention whether it is specific to having Site Isolation enabled.

Verifying

You can visit chrome://process-internals to see whether a Site Isolation mode is enabled.

If you would like to test that Site Isolation has been successfully turned on in practice, you can follow the steps below:

  1. Navigate to a website that has cross-site subframes. For example:
  2. Open Chrome's Task Manager: Chrome Menu -> More tools -> Task manager (Shift+Esc).
  3. Verify that the main page and the subframe are listed in separate rows associated with different processes. For example:
    • Tab: creis.github.io/tests/cross-site-iframe.html - Process ID = 1234
    • Subframe: https://www.chromium.org - Process ID = 5678

If you see the subframe process in Chrome's Task Manager, then Site Isolation is correctly enabled. These steps work when using the "Isolating all sites" approach above (e.g., --site-per-process). They also work when using the "Isolating certain sites" approach above (e.g., --isolate-origins), as long as the list of origins provided includes either http://csreis.github.io or https://www.chromium.org.

Recommendations for Web Developers

Site Isolation can help protect sensitive data on your website, but only if Chrome can distinguish it from other resources which any site is allowed to request (e.g., images, scripts, etc.). Chrome currently tries to identify URLs that contain HTML, XML, JSON, and PDF files, based on MIME type and other HTTP headers. See Cross-Origin Read Blocking for Web Developers for information on how to ensure that sensitive information on your website will be protected by Site Isolation.

We strongly recommend following the guidelines in Post-Spectre Web Development to protect content, which can help in browsers with and without Site Isolation support. The Mitigating Side-Channel Attacks blog post provides a good overview of these mechanisms and how they help. For example, using HTTP response headers such as Cross-Origin-Resource-Policy and Cross-Origin-Opener-Policy can help control which process a resource can load in. Consider also inspecting the Sec-Fetch- request headers in the HTTP server to identify the source of the request before deciding how to handle a request.

See also Site Isolation for web developers for more discussion of how Site Isolation can protect web page content and in which cases it might affect page behavior.