breadcrumbs: Chromium Security > page_name: site-isolation title: Site Isolation

Overview

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

Websites typically cannot 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 a second 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 certain 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.

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 other 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.

Current Status

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.

Additional protections are in place as of Chrome 77: Site Isolation has been enabled on Android devices with at least 2 GB of RAM, for sites that users log into. On desktop platforms, Site Isolation also now defends against fully compromised renderer processes and UXSS bugs.

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

  • Cross-site documents are always put into a different process, whether the navigation is in the current tab, a new tab, or an iframe (i.e., one web page embedded inside another). Note that only a subset of sites are isolated on Android, to reduce overhead.
  • Cross-site data (specifically HTML, XML, JSON, and PDF files) is not delivered to a web page's process unless the server says it should be allowed (using CORS).
  • Security checks in the browser process can detect and terminate a misbehaving renderer process (only on desktop platforms for the time being).

Known Issues

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:

  • Higher overall memory use in Chrome. On desktop in Chrome 67, this is about 10-13% when isolating all sites with many tabs open. On Android in Chrome 77, this is about 3-5% overhead when isolating sites that users log into.

For web developers:

  • Full-page layout is no longer synchronous, since the frames of a page may be spread across multiple processes. This may affect pages that change the size of a frame and then send a postMessage to it, since the receiving frame may not yet know its new size when receiving the message. One workaround is to send the new size in the postMessage itself if the receiving frame needs it. As of Chrome 68, pages can also work around this by forcing a layout in the sending frame before sending the postMessage. See Site Isolation for web developers for more details.
  • Unload handlers may not always run when the tab is closed. postMessage might not work from an unload handler (964950).
  • When debugging with --disable-web-security, it may also be necessary to disable Site Isolation (using --disable-features=IsolateOrigins,site-per-process) to access cross-origin frames.

How to Configure

For most users, no action is required. For more advanced cases, there are two ways to enable Site Isolation: isolating all sites, or isolating a list of certain sites.

1) Isolating All Sites

This mode is 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 websites are put into dedicated processes that are not shared with other sites. It can be enabled in either of the following ways:

2) Isolating Certain Sites

This mode allows you to provide a list of specific origins that will be given dedicated processes, rather than isolating all sites. The main advantage of this mode is that it typically uses less memory than isolating all sites, although it requires knowing which sites need isolation the most. If using this approach, we recommend including sites that need extra protection on the list, such as any site that you log into. (Note that subdomains are automatically included, so listing https://google.com will also protect https://mail.google.com.) This mode is automatically enabled on Android as of Chrome 77, for sites that users log into.

This mode can be manually enabled in any of the following 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.

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.

image

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 that you are using Site Isolation.

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://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://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.

Consider sending a Cross-Origin-Resource-Policy response header from your HTTP server to opt-in sensitive content into additional protections. Consider inspecting the Sec-Fetch-Site request header in the HTTP server to identify the source of the request before starting to handle the 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.