Site isolation and renderer sandboxing

A browser runs untrusted code from the internet all day. At the same time it holds your passwords, your files, your camera, and a direct line to the operating system. Modern browsers survive this by splitting the work into processes with different privileges.

The renderer process

The code that parses HTML, runs JavaScript, and paints pixels lives in a renderer process. That’s the part most exposed to attack, because it’s the part that touches web content.

So the renderer runs inside a sandbox: an operating-system restriction that takes away its ability to open files, talk to the network directly, or reach devices. When it needs any of that, it asks the privileged browser process, which checks the request first.

If an attacker finds a bug in V8 and gets code running inside the renderer, the sandbox is what stops that code from reading your documents folder.

Site isolation

A sandbox protects the machine. It doesn’t protect one site from another site that shares the same process. If your bank and a malicious page render in the same process, a renderer bug on the malicious page can read the bank’s memory.

Site isolation fixes that by giving content from different sites separate renderer processes. Cross-site iframes get their own process too. A compromised renderer then holds only the data of the site that compromised it.

Notice I said “site”, not “origin”. For this purpose Chrome groups by scheme plus registrable domain, so app.example.com and www.example.com count as the same site. It’s a coarser boundary than the origin from the earlier lessons.

Don’t build anything on the exact process model. One process per tab, per frame, or per origin is not guaranteed. Browsers make different choices on phones, on low-memory machines, and between versions.

Three layers, three jobs

• the same-origin policy limits what web code may read
• site isolation separates sites at a process boundary
• sandboxing limits what a renderer can reach in the operating system

This is defense in depth: each layer assumes the one before it may fail.

None of this makes XSS harmless. An injected script runs as the page itself, inside the page’s own process, with all of the page’s permissions. It reads what the page can read. Your app still needs output escaping, a Content Security Policy, dependencies you trust, and server APIs with the least privilege that works.

You can look at the process model in Chrome. Open a page with cross-site iframes, then Chrome’s Task Manager from the menu under More Tools. Each iframe from a different site shows up as its own subframe process. Treat it as a snapshot of today’s architecture, not a contract.