# A common misconception about the Chrome sandbox

DevFeed: [A common misconception about the Chrome sandbox](<https://devfeed.tech/articles/a-common-misconception-about-the-chrome-sandbox-21557.md>)

Original publisher: [Read original article](<http://lackingrhoticity.blogspot.com/2010/12/chrome-sandbox-common-misconception.html>)

Author: Mark Seaborn (noreply@blogger.com)

Published: 2010-12-21T00:34:00Z

Content type: article

Language: en

Sources: [Mark Seaborn](<https://devfeed.tech/sources/mark-seaborn.md>)

Topics: [Chrome](<https://devfeed.tech/topics/chrome.md>), [Security](<https://devfeed.tech/topics/security.md>), [Processes](<https://devfeed.tech/topics/processes.md>), [Document Object Model (DOM)](<https://devfeed.tech/topics/dom.md>), [Memory Safety](<https://devfeed.tech/topics/memory-safety.md>)

Tags: [browser](<https://devfeed.tech/tags/browser.md>), [chrome](<https://devfeed.tech/tags/chrome.md>), [chromium](<https://devfeed.tech/tags/chromium.md>), [memory-safety](<https://devfeed.tech/tags/memory-safety.md>), [processes](<https://devfeed.tech/tags/processes.md>), [security](<https://devfeed.tech/tags/security.md>)

## AI overview

The article explains that Chrome's sandbox does not isolate one website from another when sites share an exploited renderer process. A malicious site may use an iframe to cause another site to run in the same renderer, potentially allowing access to that site's cookies. Chrome's multi-process architecture instead provides renderer-crash containment and protection of the wider user system.

## Source excerpt

A common misconception about the Chrome web browser is that its sandbox protects one web site from another. For example, suppose you are logged into your e-mail account on mail.com in one tab, and have evil.com open in another tab. Suppose evil.com finds an exploit in the renderer process, such as a memory safety bug, that lets it run arbitrary code there. Can evil.com get hold of your HTTP cookies for mail.com, and thereby access your e-mail account? Unfortunately, the answer is yes. The reason is that mail.com and evil.com can be assigned to the same renderer process. The browser does not only do this to save memory. evil.com can cause this to happen by opening an iframe on mail.com. With mail.com's code running in the same exploited renderer process, evil.com can take it over and read the cookies for your mail.com account and use them for its own ends. There are a couple of reasons why the browser puts a framed site in the same renderer process as the parent site. Firstly, if the sites were handled by separate processes, the browser would have to do costly compositing across renderer processes to make the child frame appear inside the parent frame. Secondly, in some cases the DOM allows Javascript objects in one frame to obtain references to DOM objects in other frames, even across origins, and it is easier for this to be managed within one renderer process. I don't say this to pick on Chrome, of course. It is better to have the sandbox than not to have it. Chrome has never claimed that the sandbox protects one site against another. In the tech report "The Security Architecture of the Chromium Browser" (Barth, Jackson, Reis and the Chrome Team; 2008), "Origin isolation" is specifically listed under "Out-of-scope goals". They state that "an attacker who compromises the rendering engine can act on behalf of any web site". There are a couple of ways that web sites and users can mitigate this problem, which I'll discuss in another post. However, in the absence of tho