Site Isolation is a browser security feature that places content from different websites into separate processes and sandboxes on the user’s device. This limits how one site can affect another and helps contain certain attacks. It is a process-level control, not a full replacement for broader browser threat protection.
Expanded Definition
Site isolation is a browser architecture choice that separates web content from different sites into distinct operating-system processes and sandboxes. The practical aim is containment: if one site is compromised, the browser reduces the chance that the same fault or exploit can directly reach data or execution context belonging to another site. It is narrower than “the browser is secure” and narrower than a complete anti-exploitation strategy.
For practitioners, the boundary that matters most is process separation versus full trust separation. Site isolation can reduce the blast radius of renderer compromise, but it does not remove phishing risk, malicious downloads, weak extensions, or vulnerabilities in browser components that sit outside the isolated site boundary. Guidance is consistent across major browsers, although implementation details vary by platform and release. The key idea is that the browser treats website boundaries as security boundaries, even when a user appears to be browsing within a single tabbed session.
Examples and Use Cases
Site isolation shows up most visibly in browsers that allocate different websites to different renderer processes, especially when a page includes content from several origins. It is also relevant in enterprise environments where managed browsers must contain exposure from high-risk web applications.
- A user opens a banking site and a separate advertising or analytics site. Site isolation helps keep those contexts from sharing the same execution process.
- A webmail page embeds content from another domain. Isolation reduces the chance that a compromise in the embedded content can directly access the mail origin.
- An organisation uses a browser to access internal SaaS applications. Separate site processes can narrow the impact of a browser renderer escape.
- A security team tests whether a browser build enforces process-per-site or a looser process-sharing model, because that affects containment assumptions.
The trade-off is resource cost. More isolation usually means more memory use and more process overhead, so operators sometimes balance protection against performance and device constraints.
Security Implications
When site isolation is absent or weakened, a single renderer compromise can become much more valuable to an attacker because it may expose data from multiple sites in one process. That makes browser exploitation more attractive as a pivot into session content, authenticated applications, and sensitive browser state.
Misunderstanding site isolation can also create false assurance. A team may assume that “separate tabs” or “same browser session” already implies containment, when the real control depends on how the browser maps sites to processes and sandboxes. Weaknesses often appear as cross-site data exposure, broader impact from a memory-corruption bug, or reduced effectiveness of containment after a successful exploit. For defenders, the observable symptom is not usually a visible failure in normal browsing, but a larger-than-expected blast radius once a browser bug is exercised.
Domain and Governance Relevance
Site isolation belongs first to browser security and endpoint containment. It matters in security governance because it changes how organisations reason about compromise scope, especially on managed devices that access sensitive web applications. The control is relevant when browser choice, hardened configurations, and patch strategy are part of the security baseline.
The NHI lens is only indirect here. Site isolation is not a machine-identity control, but it can affect the safety of browser-based access to systems that rely on sessions, tokens, or authenticated workflows. That means identity teams should not treat it as an IAM replacement, yet they should recognise that stronger browser containment can reduce the impact of web-session compromise. The practical governance question is whether the organisation treats browser process isolation as a baseline containment control or as an optional hardening feature.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-3 — Access Control for Users and Devices | Site isolation narrows cross-site access paths in browser sessions. |
| PR.IP-1 — Baseline Configuration | Browser isolation depends on hardened, validated configuration choices. | |
| Recommendation — Apply PR.AC-3 to limit cross-context access and contain browser session exposure. Use PR.IP-1 to enforce a hardened browser baseline that preserves isolation settings. | ||
| CIS Controls v8 | 4 — Secure Configuration of Enterprise Assets and Software | Browser isolation is a secure configuration choice on managed endpoints. |
| 7 — Continuous Vulnerability Management | Isolation reduces blast radius but does not remove browser exploit risk. | |
| Recommendation — Use CIS Control 4 to standardise browser settings that maintain process isolation. Use CIS Control 7 to patch browser vulnerabilities that can still bypass containment. | ||
| MITRE ATT&CK | T1189 — Drive-by Compromise | Site isolation limits the impact of web-delivered exploitation attempts. |
| Recommendation — Track T1189 activity and validate that browser containment reduces exploitation impact. | ||
Related resources from NHI Mgmt Group
- What is the difference between sandbox mode and true network isolation for AI workloads?
- How should security teams handle auditability in multi-site data center environments?
- When should organisations use entity-level isolation for access reviews?
- How should teams enforce tenant isolation in multi-tenant IAM?
