Sandboxing, COOP/COEP, and Site Isolation

## What the browser is actually deciding Before a browser renders a document inside a frame, it asks whether that document consents to being embedded by the documents above it. Nothing else stops the embed: the same-origin policy governs *access* between documents, not *inclusion*, so any page on the web may put your URL in an `<iframe>` and render it. Framing is therefore opt-out, and the opt-out must come from the framed response itself — the embedder is the untrusted party here and cannot be asked to behave. The practical reason to care is that a framed page still runs with its own cookies and session. An embedder that cannot read the frame's DOM can still position it, make it transparent, and overlay bait so that a click lands on a real control inside your page. ## X-Frame-Options: the legacy switch `X-Frame-Options` predates any specification effort and offers exactly two usable values: ``` X-Frame-Options: DENY X-Frame-Options: SAMEORIGIN ``` `DENY` refuses all framing. `SAMEORIGIN` allows it only from your own origin. A third value, `ALLOW-FROM <origin>`, appeared in old Firefox and Internet Explorer but was never implemented in Chromium or WebKit, and is now obsolete — treat it as nonexistent. Consequently `X-Frame-Options` cannot express "my origin plus one named partner". It must be sent as a response header. A `<meta http-equiv="X-Frame-Options">` element does nothing. ## CSP frame-ancestors: the current mechanism ``` Content-Security-Policy: frame-ancestors 'none' Content-Security-Policy: frame-ancestors 'self' https://partner.example https://*.partner.example ``` The directive takes a source list, so scheme, host, port and host wildcards are all expressible. `'none'` corresponds to `DENY` and `'self'` to `SAMEORIGIN`, with everything in between now available. Two behavioural details matter more than the syntax: **It checks the whole ancestor chain.** If your page sits inside a frame on `b.example`, which is itself framed by `a.example`, then both `b.example` and `a.example` must match your source list. That closes the wrapping trick where an allowed partner is itself embedded by an attacker. **It is ignored in a meta tag.** `frame-ancestors`, along with `report-uri` and `sandbox`, has no effect when the policy is delivered via `<meta http-equiv="Content-Security-Policy">`. The browser has already committed to loading the document by the time it parses markup, so the decision has to live in the response headers. A policy that looks correct in the HTML source and does nothing in production is almost always this mistake. ## Precedence when both are sent Browsers that support `frame-ancestors` ignore `X-Frame-Options` when both are present. This is not a "most restrictive wins" merge. If a page sends `X-Frame-Options: DENY` alongside `Content-Security-Policy: frame-ancestors https://partner.example`, the partner embed succeeds. Teams that add a permissive CSP for one integration and leave a strict legacy header in place as a supposed backstop have, in fact, loosened the policy everywhere. Keeping `X-Frame-Options` around is still reasonable as a floor for very old user agents, but it must be kept *consistent* with the CSP, not treated as an independent guard. ## Diagnosing the partner's report Open the partner page, look at the console — browsers report a refusal to display in a frame and name the offending directive or header — and then inspect the framed URL's response headers directly: ``` curl -sI https://app.example/report | grep -iE 'x-frame-options|content-security-policy' ``` If the header is present, the fix is to add the partner origin to `frame-ancestors` (and to remove or align any `X-Frame-Options`). If it is absent, the block is coming from somewhere else — a CDN or reverse proxy injecting a default, or a different mechanism such as a cookie that is not sent in a third-party context, which produces a blank frame rather than a refusal. ## What these headers do not do They control only whether your document may be *embedded*. They say nothing about what the framed page may do once loaded, and nothing about non-document resources — an image or script of yours can still be included by any page unless you send `Cross-Origin-Resource-Policy`. They also do not apply to top-level navigation: a link to your page always works. Finally, they are enforced by the browser, so a server-side fetch of the same URL is unaffected; if the content itself must not leave your origin, authorisation, not a framing header, is the control.