What does adding the sandbox attribute to an HTML <iframe> do, and how do tokens such as allow-scripts and allow-forms change that?

## The shape of the attribute `sandbox` is a *space-separated token list* attribute on `<iframe>`. Three states matter and they are easy to confuse: ```html <!-- 1. no sandbox: the frame has every capability a normal document has --> <iframe src="https://widget.example/embed"></iframe> <!-- 2. empty value (or the bare attribute): every restriction applied --> <iframe sandbox src="https://widget.example/embed"></iframe> <iframe sandbox="" src="https://widget.example/embed"></iframe> <!-- 3. selective: restrictions applied, then two of them lifted --> <iframe sandbox="allow-scripts allow-forms" src="https://widget.example/embed"></iframe> ``` The counter-intuitive part is that the *empty* value is the strictest configuration and the *absent* attribute is the loosest. Candidates who read `sandbox=""` as "an empty sandbox, so nothing is sandboxed" have it exactly backwards. ## What the full sandbox actually removes With no tokens, the browser removes, among other things: - **Script execution.** Inline and external scripts in the framed document do not run at all. The document still parses and renders, which is why people mistakenly believe scripts are running. - **Form submission.** A `<form>` inside the frame will not submit. - **Popups.** `window.open()` returns `null` and `target="_blank"` links do nothing. - **Top-level navigation.** The frame cannot point the containing browser tab somewhere else — the classic "an ad in a frame hijacked the whole page" attack. - **Downloads**, **pointer lock**, **fullscreen**, **screen orientation lock**, and **modal dialogs** (`alert`, `confirm`, `prompt`, `print`). - **Automatic playback** of media that would otherwise autoplay. ## The opaque origin — the piece people miss A sandboxed document is placed in a **unique opaque origin**: an origin that matches nothing, not even another copy of itself. The practical consequences are larger than the capability list: - `document.cookie` yields nothing useful and cannot set cookies. - `localStorage` and `sessionStorage` access throws a `SecurityError`. - Requests the frame makes to its own server are *cross-origin*, so they arrive without cookies and are subject to CORS. - The frame is cross-origin to the embedding page, so neither can touch the other's DOM. That last point is what makes `sandbox` a containment tool rather than a cosmetic one, and it is why `allow-same-origin` — the token that restores the document's real origin — is the token to think hardest about. ## The token vocabulary The tokens that come up in practice are `allow-scripts`, `allow-forms`, `allow-same-origin`, `allow-popups`, `allow-popups-to-escape-sandbox`, `allow-modals`, `allow-downloads`, `allow-pointer-lock`, `allow-presentation`, `allow-orientation-lock`, `allow-top-navigation`, and `allow-top-navigation-by-user-activation`. Each grants exactly one thing back; there is no wildcard token and no way to express "everything except X" other than by listing what you want. Two of these deserve a caveat in an interview answer. `allow-top-navigation` lets the frame navigate the whole tab unconditionally; `allow-top-navigation-by-user-activation` is the safer variant that only permits it as the direct result of a user gesture — prefer it. And `allow-same-origin` combined with `allow-scripts`, when the framed content comes from your own origin, effectively cancels the sandbox, because the framed script becomes same-origin with the embedder and can reach out and delete the `sandbox` attribute from its own frame element. ## How this differs from neighbouring attributes `sandbox` is not the only restricting attribute on `<iframe>`, and mixing them up is a common stumble. `allow` is a separate attribute governing delegation of powerful features (camera, microphone, geolocation, payment) to the frame; `referrerpolicy` governs what referrer information the frame's requests carry; `loading="lazy"` is a fetch-timing hint. None of them substitute for `sandbox`, and `sandbox` does not substitute for them: a fully sandboxed frame is still a frame that made a network request to a third party. One more boundary worth stating plainly: `sandbox` is a control the **embedder** applies to content it embeds. It gives the embedded site no protection whatsoever, and it does nothing to stop *your* page from being embedded by someone else — that is a decision the framed site expresses in its HTTP response, not something you can assert from markup. ## Practical discipline Start at `sandbox=""`, load the embed, see what breaks, and add the single token that fixes it. Write the tokens in the markup rather than adding them from script, because a reader of the HTML should be able to see the frame's full capability set in one place. And give every `<iframe>` a `title` while you are there — assistive technology announces the frame by that string, and "iframe" is what a user hears without it.