A browser sandbox is the set of security boundaries that confine web content so that code from a website cannot freely access the operating system, the file system, other applications or data from other sites. Among browser technologies, the term covers two layers: the process sandbox, which restricts what browser processes may do at the operating-system level, and the web platform sandbox, which restricts what page scripts may do.
The sandbox exists because browsers run untrusted code from millions of sources. Its design assumes that some of that code will eventually exploit a bug, and it aims to ensure that a compromised page cannot escalate into a compromised computer.
How the process sandbox works
Modern browsers use a multi-process architecture. A privileged browser process manages windows, storage and network access, while web content is parsed, laid out and executed in separate renderer processes. The renderer processes run with minimal operating-system privileges: they cannot open files, start programs or access most system calls directly.
When a renderer needs something outside its boundary, such as reading a file the user selected or sending a network request, it asks the browser process through inter-process communication. The browser process validates each request before acting. An attacker who gains code execution in a renderer must therefore find a second vulnerability in the browser process or the operating system to escape, a so-called sandbox escape.
| Platform | Main mechanisms | Effect on renderer processes |
|---|---|---|
| Windows | Restricted tokens, job objects, integrity levels, AppContainer | Very limited access to files, registry and devices |
| Linux | Namespaces and seccomp-bpf system call filters | Isolated view of the system, filtered system calls |
| macOS | Seatbelt sandbox profiles | Declarative limits on files and services |
| Android | Isolated processes and SELinux policies | Separate unprivileged identity per process |
Site isolation and the web platform sandbox
The process sandbox protects the computer, but sites also need protection from each other. Site isolation places pages from different sites into different renderer processes, so that memory belonging to one site is not present in a process running another site’s code. This became especially important after speculative execution attacks such as Spectre showed that code could read memory within its own process.
Above the process level, the web platform sandbox is a set of rules that limit scripts regardless of process layout. The same-origin policy prevents scripts from reading data from other origins, permissions gate access to the camera, microphone and location, and the iframe `sandbox` attribute lets developers strip capabilities from embedded content.
| Layer | Protects against | Enforced by |
|---|---|---|
| Process sandbox | Malicious code reaching the operating system | Operating-system privilege restrictions |
| Site isolation | One site reading another site’s memory | Separate processes per site |
| Same-origin policy | Scripts reading cross-origin data | Browser security checks |
| Permission prompts | Silent access to sensitive devices | User consent and browser settings |
| Iframe sandbox attribute | Embedded content acting with full rights | Developer-defined restrictions |
The iframe sandbox attribute in practice
For web developers, the most direct contact with the browser sandbox is the `sandbox` attribute on an iframe. An empty sandbox attribute applies all restrictions: no scripts, no forms, no popups, no top-level navigation and a unique opaque origin. Specific capabilities are then re-enabled with tokens.
| Token | Re-enables | Risk if granted |
|---|---|---|
allow-scripts | JavaScript execution | Scripts run inside the frame |
allow-same-origin | The frame’s real origin | Combined with scripts, the frame can remove its own sandbox |
allow-forms | Form submission | Data can be sent to other servers |
allow-popups | Opening new windows | Unwanted windows or phishing pages |
allow-top-navigation | Navigating the parent page | Redirection of the whole tab |
The combination of `allow-scripts` and `allow-same-origin` for content from the same origin as the parent effectively disables the sandbox, because the framed script can reach into the parent and remove the attribute. Untrusted content should therefore be served from a separate origin when scripts must run.
Browser sandbox compared with related concepts
The browser sandbox is often discussed alongside other isolation techniques. They differ in what they isolate and at what cost, and they complement rather than replace each other.
| Approach | Isolation unit | Typical overhead | Main use |
|---|---|---|---|
| Browser process sandbox | Renderer process | Low to moderate memory cost | Containing exploited web content |
| Same-origin policy | Origin | Negligible | Separating data between sites |
| Virtual machine | Entire operating system | High | Isolating untrusted applications |
| Remote browser isolation | Browser running on a server | Network latency | High-security corporate browsing |
Limitations of the browser sandbox
- The sandbox does not stop phishing: a page that tricks users into typing passwords needs no escape at all.
- Sandbox escapes exist: attackers chain a renderer bug with a browser or kernel bug, which is why prompt browser updates remain essential.
- Extensions run with more privileges than web pages and can bypass protections the sandbox gives to sites.
- Memory costs limit isolation: on low-memory devices, browsers may group more sites into one process, weakening site isolation.
- Misconfigured iframes can grant embedded content far more power than intended.
The idea in brief
Every website you open runs code on your device, and you cannot check whether that code is safe. The browser sandbox is a locked room in which that code runs, with no direct door to your files, programs or other websites.
Think of a play area with a fence. Children can run, build and make a mess inside, but they cannot wander off onto the street. If a website misbehaves or is malicious, the damage stays inside the fence, and the browser decides carefully what may pass through the gate.
A practical scenario
An online learning platform lets students submit small HTML and JavaScript exercises that teachers preview in the browser. Running student code directly in the platform’s page would allow one submission to read the teacher’s session data or redirect the whole application.
The development team serves submissions from a separate domain and displays them in an iframe with sandbox="allow-scripts" only. Scripts run, but the frame has an opaque origin, cannot submit forms, open popups or navigate the parent page. A test submission that tries to read cookies and redirect the tab fails silently, while legitimate exercises with animations and calculations work normally. The platform gains safe live previews without building a separate execution service.