Why do the <iframe> sandbox tokens allow-scripts and allow-same-origin, used together on content served from your own origin, amount to no sandbox at all?

## The two tokens, separately A sandboxed `<iframe>` is placed in a **unique opaque origin** — an origin equal to nothing else — and has script execution disabled. Two tokens undo those specific restrictions: - `allow-same-origin` stops the origin substitution. The document keeps the origin it was actually served from. - `allow-scripts` re-enables script execution inside the frame. Each on its own is defensible. `sandbox="allow-scripts"` gives you a frame that can run code but is cross-origin to everything, has no cookies and no storage, and cannot touch the embedder's DOM. `sandbox="allow-same-origin"` gives you a frame with its real origin but no ability to run code. ## Why the combination collapses Put them together on content whose origin is *your* origin and the containment is gone. Same-origin plus scripting is precisely the condition under which one document may reach into another: ```html <!-- embedder at https://app.example --> <iframe id="embed" sandbox="allow-scripts allow-same-origin" src="https://app.example/widget"></iframe> ``` ```js // running inside https://app.example/widget const self = window.frameElement; // reachable: same origin as the parent self.removeAttribute('sandbox'); // the restrictions are declared by markup... self.src = self.src; // ...and re-applied only on load ``` The sandbox flags are computed when the frame **navigates**. Removing the attribute does not retroactively lift restrictions on the currently loaded document, but reloading the frame — by reassigning `src`, or by navigating itself — produces a fresh document that is created with no sandbox flags at all. From that moment the frame is an ordinary same-origin document: it can read `document.cookie` for your origin, read and write your `localStorage`, and script your page's DOM. Even without the escape trick, same-origin access alone already means the frame can do anything your own first-party script could do — the removal step just makes the point unmissable. ## The condition that actually matters The defect is not the token pair in the abstract; it is the token pair **plus shared origin**. Consider two embeds: - `https://app.example` framing `https://app.example/widget` with both tokens — broken. Same origin, so the frame is inside your trust boundary. - `https://app.example` framing `https://widget-sandbox.example/embed` with both tokens — meaningfully different. `allow-same-origin` restores *the widget's* origin, not yours. The frame gets its own cookies and storage, which is often exactly what a third-party embed legitimately needs, and it still cannot touch `app.example` because the same-origin check between the two documents fails. This is why the standard advice for hosting untrusted content — a user-authored HTML preview, a plugin surface, a rich-text render — is to give it a **separate origin**, not merely a separate path. A path is not an origin; `https://app.example/sandbox/` is the same origin as the rest of the site and buys you nothing. ## Choosing a configuration Work backwards from what the frame needs: - **Untrusted content, needs scripting, no session of its own:** `sandbox="allow-scripts"` and no `allow-same-origin`. This is the strongest useful configuration and is what code-playground-style previews want. Accept that the frame has no storage and no cookies. - **Third-party embed with its own login, served from its own origin:** both tokens are acceptable, because the origin separation carries the containment. Add only the extra tokens it demonstrably needs. - **Untrusted content you insist on serving from your own origin:** there is no safe token set. Move it to another origin, or do not frame it. ## What a good answer sounds like An interviewer is checking three things. First, that you can state the mechanism concretely — `frameElement`, `removeAttribute`, reload — rather than repeating "it's insecure". Second, that you name the *condition*: same origin as the embedder, because a candidate who says "never combine those tokens" is over-generalising and will block legitimate third-party embeds. Third, that your fix is origin separation rather than a cleverer token list, because no arrangement of tokens can re-establish a boundary that shared origin has already dissolved. One related check worth mentioning: the trick works because the attribute lives in the parent's markup and the frame can reach the parent's DOM. If the frame cannot reach the parent DOM — the cross-origin case — the attribute is unreachable and the escape does not exist.