iframe sandbox.

The sandbox attribute on an <iframe>, defined in the HTML Living Standard, applies a least-privilege policy to embedded content. With an empty value (sandbox="") it disables scripts, plugins, form submission, top-level and same-origin navigation, popups, pointer-lock, autoplay, and the Pointer Lock and Presentation APIs, and forces the frame into a unique opaque origin so it cannot read the parent's cookies, localStorage, or DOM. Capabilities are re-granted one token at a time — allow-scripts, allow-same-origin, allow-forms, allow-popups, allow-modals, allow-downloads, allow-top-navigation-by-user-activation.

The critical footgun: combining allow-scripts allow-same-origin returns the frame to its real origin and lets it run JavaScript, so sandboxed code can simply reach into its own DOM and remove the sandbox attribute from a nested frame — nullifying the protection. For hosting genuinely untrusted content, isolate it on a separate origin and pair the sandbox with Content-Security-Policy: sandbox (which cannot be stripped by markup) and Cross-Origin-Opener/Embedder policies. Sandboxing underpins safe rendering of ads, rich-text previews, and third-party widgets; Google's Caja and modern services like CodePen and JSFiddle rely on sandboxed frames on throwaway origins to run attacker-controlled code without endangering the host page.

flowchart TD
  A[Parent page] --> B["&lt;iframe sandbox&gt;<br/>embed untrusted content"]
  B --> C{Which tokens set?}
  C -->|"sandbox=&quot;&quot; (empty)"| D[Opaque origin, no scripts,<br/>no forms, no navigation]
  C -->|allow-scripts only| E[Scripts run, still<br/>opaque origin - safe]
  C -->|"allow-scripts +<br/>allow-same-origin"| F[Real origin + scripts:<br/>frame can strip its own<br/>sandbox = escape]
  E --> G[Add CSP: sandbox header<br/>separate origin = defence-in-depth]