Site isolation and renderer sandboxing

A browser renders untrusted code from the internet while also handling files, devices, credentials, and operating-system APIs. Modern browsers reduce that risk by separating responsibilities and privileges.

A renderer process handles web content with restricted operating-system access. Its sandbox limits what exploited renderer code can directly reach. Site isolation can also keep content from different sites in separate renderer processes, reducing the cross-site data present in a compromised process.

The exact process model is an implementation detail. One process is not guaranteed per tab, iframe, or origin, and browsers make different choices based on platform and resources.

These layers solve different parts of the problem:

• the same-origin policy restricts what web code may read
• site isolation separates sensitive content at a process boundary
• sandboxing restricts a renderer’s access to the operating system

They are defense in depth. They do not make an XSS bug harmless: injected script still runs with the affected page’s permissions and can read or modify data available to that page.

In Chrome, open the browser’s Task Manager on a page with cross-site iframes and compare its processes. Treat what you see as evidence of that browser’s current architecture, not a contract your application can depend on. Your application still needs output escaping, a considered Content Security Policy, safe dependencies, and least-privilege server APIs.