Chromium‎ > ‎Chromium Security‎ > ‎

Site Isolation


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 will also make 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 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.

Current Status

Site Isolation has been enabled by default in Chrome 67 on Windows, Mac, Linux, and Chrome OS to help to mitigate attacks that are able to read otherwise inaccessible data within a process, such as speculative side-channel attack techniques like Spectre/Meltdown.  Site Isolation reduces the amount of valuable cross-site information in a web page's process, and thus helps limit what an attacker could access.

In addition, Site Isolation also offers more protection against a certain type of web browser security bug, called universal cross-site scripting (UXSS).  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.  Site Isolation can help protect sites even when some forms of these UXSS bugs occur.

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).
  • Cross-site data (specifically HTML, XML, and JSON files) is not delivered to a web page's process unless the server says it should be allowed (using CORS).
There is additional work underway to let Site Isolation offer protection against even more severe security bugs, where a malicious web page gains complete control over its process (also known as "arbitrary code execution").  These protections are not yet fully in place.

We are investigating options for enabling Site Isolation on Android as well.

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.  On Chrome for desktop, a few known issues remain:

For users:
  • Higher overall memory use in Chrome (about 10-13% in Chrome 67 when isolating all sites with many tabs open).

  • Clicks on hidden cross-site iframes do not work.  This is expected to be relatively uncommon in practice.

  • Certain sites might have printing issues with cross-site subframes.  Saving the page locally and then printing can work around the bug.  These are fixed in M70.

  • A few additional clicking and scrolling issues may be observed on certain sites.  Fixes for many of these are already in Chrome 68.
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.  In 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.

  • Beforeunload handlers are not working in cross-site subframes, and unload handlers may have issues with postMessage.  We are working on fixes for these.

  • In Chrome's DevTools, cookies and other request headers are not shown in the network panel for cross-site subresource requests.  There are also issues with the DOM storage view, security panel, performance panel, and with scrolling over cross-site iframes in mobile device emulation mode, all of which are fixed in Chrome 68.

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

  • Website testing frameworks using ChromeDriver should update to at least version 2.37 to support cross-site iframes.
Note that there are more significant issues and overhead when enabling Site Isolation on Android, where it is still considered experimental.  We are working to resolve these issues so that Site Isolation can be enabled more broadly.

How to Configure

There are two ways to enable Site Isolation: isolating all sites, or isolating a list of certain sites.

1) Isolating All Sites

Note that this mode is enabled by default for 99% of Chrome users on Windows, Mac, Linux, and Chrome OS, as of Chrome 67.  The instructions below can still be useful to ensure the mode is enabled or for Chrome on Android.

This mode is easier to enable and ensures that all websites are put into dedicated processes that are not shared with other sites.  It can be enabled in any 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 will also protect  This mode can be enabled in either of the following ways:
  • Use command line flags to start Chrome with --isolate-origins followed by a comma-separated list of origins to isolate.  For example:
    Be careful not to include effective top-level domains (e.g., or; see the full list at, because these will be ignored.

  • Or, use an Enterprise Policy to enable IsolateOrigins within your organization.

Both "Isolating All Sites" and "Isolating Certain Sites" work on Chrome for Windows, Mac, Linux, and ChromeOS.  "Isolating All Sites" also works on Chrome for Android, but only via chrome://flags#enable-site-per-process.  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.

There are currently field trials in progress that may enable these modes automatically.

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 "Opt-out (not recommended)," and restarting.

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

Note that some issues might be resolved by turning off just the data blocking feature (called Cross-Origin Read Blocking, or CORB), which leaves some of the protections from process isolation in place.  To disable CORB specifically, start Chrome with the following command line flag: 

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.


In Chrome 68 and later, 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: - Process ID = 1234
    • Subframe: - 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 or

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, and JSON 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.

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.