Three ways to ask who embedded your iframe, and only one the host cannot switch off

The asymmetry is what makes the ordering non-negotiable. `document.referrer` is a value the embedding page hands over, and the dev.to guide lists three independent switches that reduce it to an empty string: a meta tag, a `Referrer-Policy` response header, and a `referrerpolicy` attribute on the iframe element itself ^{[4] [1]}. Any one of them, set by someone who has never heard of your widget, and the frame loads with no record of the page around it ^[4]. `window.location.ancestorOrigins` is read off the frame's own location object, which is why the guide checks it before it checks anything the host supplies ^{[7] [4]}.

Then the nesting arithmetic. In the guide's worked example, main-portal.com wraps agency-host.com, which wraps my-widget.com ^[5]. Inspecting the immediate parent returns agency-host.com, which is not the site in the address bar ^[5]. `ancestorOrigins` holds every ancestor in order, so that stack yields two entries and the useful one is index 1, the last ^{[6] [2]}. A widget distributed through integrators and allowlisting on the nearest parent will therefore authorize the reseller and never learn the publisher ^[5].

The last tier is where the cost sits. When the first two checks return nothing, the guide falls through to a `postMessage` handshake with a three-second timeout ^[9]. A handshake needs a second party, so the tier that runs after everything else has failed is the one the widget cannot complete on its own ^[9]. Three seconds is a long wait for code deciding whether it is permitted to render at all ^[3]. When the page is not framed at all, the same helper parses the referrer or reports `Direct Access` ^[10].

Coverage is the part to read carefully. The guide credits `ancestorOrigins` to Chrome, Edge, Safari and Opera, and names no other engine ^[8], while stating outright that no single method works everywhere ^[11]. On the browsers it names, tier one answers and the question of who embedded you is settled locally ^{[7] [8]}. Anywhere else, the widget is back to asking the host page for the answer, by referrer or by handshake, and the host may decline both ^{[4] [9]}. That is the real shape of iframe domain authorization: a property the browser volunteers on some engines, and a favour on the rest.