# Threat Model And Defenses Against Compromised Renderers Given the complexity of the browser, our threat model must use a "defense in depth" approach to limit the damage that occurs if an attacker finds a way around the Same Origin Policy or other security logic in the renderer process. For example, the combination of Chrome's sandbox, IPC security checks, and Site Isolation limit what an untrustworthy renderer process can do. They protect Chrome users against attackers, even when such attackers are able to bypass security logic in the renderer process. For other arguments for the "defense in depth" approach and why our threat model covers compromised renderers, please see [the Site Isolation motivation](https://www.chromium.org/Home/chromium-security/site-isolation#TOC-Motivation). In a compromised renderer, an attacker is able to execute arbitrary native (i.e. non-JavaScript) code within the renderer process's sandbox. A compromised renderer can forge malicious IPC messages, impersonate a Chrome Extension content script, or use other techniques to trick more privileged parts of the browser. The document below gives an overview of features that Chrome attempts to protect against attacks from a compromised renderer. Newly discovered holes in this protection would be considered security bugs and possibly eligible for the [Chrome Vulnerability Rewards Program](https://www.google.com/about/appsecurity/chrome-rewards/). [TOC] ## Site Isolation foundations Most of the other protections listed in this document implicitly assume that attacker-controlled execution contexts (e.g. HTML documents or service workers) are hosted in a separate renderer process from other, victim contexts. This separation is called [Site Isolation](https://www.chromium.org/Home/chromium-security/site-isolation) and allows the privileged browser process to restrict what origins a renderer process is authorized to read or control. The privilege restriction can be implemented in various ways - see the "protection techniques" listed in other sections in this document. One example is validating in the browser process whether an incoming IPC can legitimately claim authority over a given origin (e.g. by checking via `CanAccessDataForOrigin` if the process lock matches). Another example is making sure that capabilities handed over to renderer processes are origin-bound (e.g. by setting `request_initiator_origin_lock` on a `URLLoaderFactory` given to renderer processes). Yet another example is making security decisions based on trustworthy knowledge, calculated within the privileged browser process (e.g. using `RenderFrameHost::GetLastCommittedOrigin()`). Compromised renderers shouldn’t be able to commit an execution context (e.g. commit a navigation to a HTML document, or create a service worker) in a renderer process hosting other, cross-site execution contexts. On desktop platforms all sites (site = scheme plus eTLD+1) should be isolated from each other. On Android, sites where the user entered a password should be isolated from each other and from other sites. **Known gaps in protection**: - No form of Site Isolation is active in Android WebView. See also https://crbug.com/769449. - No form of Site Isolation is active in content hosted within `` HTML tags. See also https://crbug.com/614463. - Frames with `