Ancestor navigation conformance probe

Can a cross-origin iframe move the page it is embedded in?

Every navigation vector a child frame can reach for, fired at an ancestor browsing context, across child origin source crossed with sandbox tokens crossed with ancestor targeted. Outcomes come from two independent sources: what the client can see happening to the victim frame, and what the server saw in the request headers. The second one is what makes sandboxed results legible, because a spawned tab with an opaque origin and no opener can still be seen making an HTTP request.

Environment

Run configuration

Beacon

Child headers

Beacon headers

Child origin source

Child sandbox tokens

Ancestor to attack window.parent non-top ancestor, safe, fully automatic window.top runs in a popup so it cannot navigate this tab away

User activation Add a gesture-driven pass fired from a real click inside the child frame. The server confirms it independently via Sec-Fetch-User.

Live stage

The child frame is rebuilt before every probe, so no test inherits a mutated document, a spent user activation, or a stray base element from the one before it.

Results

Vector

NAVIGATED SPAWNED — a new top-level context CLOSED THREW INERT CHILD — moved itself instead DELIVERED

Log

Reading the results

The rule being measured

The allowed-to-navigate algorithm has no same-origin condition for ancestors. A child may navigate an ancestor regardless of origin, gated only by the initiator's own sandboxing flags: the sandboxed navigation flag blocks navigating a non-top ancestor, and the top-level variants gate the top. Chromium and WebKit add an unstandardised intervention requiring user activation before a frame that is cross-origin with the top may navigate it. That intervention is top-specific, so the parent and top columns can legitimately disagree.

What only the server can tell you

Sec-Fetch-Dest distinguishes a top-level navigation from a frame navigation, which is SPAWNED versus NAVIGATED without needing script in the target. Sec-Fetch-User is sent only when the browser considered the navigation user activated, which is the browser's own determination rather than the child's guess. Origin arrives on POST navigations and reads null for an opaque initiator, which settles whether a given profile really is opaque instead of leaving it to inference. Note that Safari does not send Sec-Fetch-User, so treat its absence there as unknown rather than as no activation.

Origin is not site

Two subdomains of one registrable domain are cross-origin but same-site. Behaviours keyed on site rather than origin, including storage partitioning and Sec-Fetch-Site, will not separate under a subdomain-only setup. Add a child origin on a different registrable domain to get a genuine cross-site column; the source list below labels each origin with its relationship to this page.

Response header knobs

The child and beacon header fields take raw query fragments. Recognised keys are csp, coop, coep, corp, xfo, referrer-policy and permissions-policy. The interesting one is csp=sandbox allow-scripts, which applies sandbox flags through the header path rather than the attribute path, and which a document can apply to itself.