Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
You cannot directly read a cross-origin parent page’s domain or DOM from JavaScript running inside an iframe. The browser’s same-origin policy prevents that access. If the parent cooperates, use window.postMessage() to request and disclose only the information the iframe needs, then validate every message before using it.
Why the iframe cannot read its parent
A web origin consists of the scheme, host, and port. For example, https://app.example.com and http://app.example.com are different origins, as are https://app.example.com and https://app.example.com:8443. Sharing a registrable domain does not make two pages same-origin.
An iframe can obtain a reference to its parent with window.parent, but that reference does not grant access to a cross-origin parent’s properties or document. The same-origin policy restricts what the child can read. See MDN’s same-origin policy guide and MDN’s iframe reference.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Use postMessage when both pages can cooperate
window.postMessage() is the standard mechanism for communication between pages from different origins. A child can send a message through window.parent; a parent that holds the iframe element can message its contentWindow. These references enable messaging, not unrestricted cross-origin access. See MDN’s postMessage() reference and MDN’s contentWindow reference.
#1 Best Overall
Agree on the expected origins and a small message format. In this example, the child asks for the parent’s serialized origin, and the parent replies only to a request from the expected child in the known iframe. Replace the example origins with the exact origins for your application.
// Child iframe: request only the value it needs from the parent.
window.parent.postMessage(
{ type: "request-parent-origin" },
"https://parent.example"
);
// Parent page: accept a request from the expected child in this iframe.
const frame = document.querySelector("iframe");
window.addEventListener("message", (event) => {
if (event.origin !== "https://child.example") return;
if (event.source !== frame?.contentWindow) return;
if (event.data?.type !== "request-parent-origin") return;
event.source.postMessage(
{ type: "parent-origin", value: window.location.origin },
event.origin
);
});
// Child iframe: accept the reply only from its expected parent.
window.addEventListener("message", (event) => {
if (event.origin !== "https://parent.example") return;
if (event.source !== window.parent) return;
if (event.data?.type !== "parent-origin") return;
if (typeof event.data.value !== "string") return;
// Use the value only for the purpose your application expects.
});The example shows the API shape; it is not a tested, drop-in implementation. It assumes the parties know each other’s origins and that the parent can identify the relevant iframe. Production code should also account for when listeners are installed, multiple frames, navigation, and a message schema suited to the application. The HTML Living Standard’s web messaging section describes the platform mechanism.
Rank #2
Validate messages before acting on them
A message event is input, not proof that a request is safe. Apply checks on both sides:
- Set
targetOriginto the recipient’s exact origin when it is known; avoid"*"for sensitive data. - Compare
event.originwith the exact expected sender origin. - Where possible, compare
event.sourcewith the expected window, such as the known iframe’scontentWindowor the child’swindow.parent. - Check the message type and validate the payload’s structure, types, and allowed values before using it.
- Return only the minimum information needed. A parent should decide what it is willing to disclose rather than treating every child request as trusted.
The origin check identifies the sender’s origin at the time the message was sent; source and payload checks help ensure the message comes from the expected window and fits the protocol. Design the trust policy for the actual application rather than relying on any one check alone.
Choose who initiates the exchange
Parent sends the value
If the parent controls the iframe setup, it can send the necessary value once the child is ready. This avoids a request round trip, but the parent still needs a reliable readiness strategy and should use the child’s expected origin as the target.
Child requests the value
If the iframe owns the interaction, it can request the value through window.parent. The parent can validate the requester and choose whether to reply and what to disclose. This is the pattern in the example above.
Rank #4
In either design, agree on the expected origins, disclosure policy, and message format. Navigation, multiple frames, and sandbox settings can affect which window is communicating and what origin is reported, so account for them in the application.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWhy document.domain is not the modern fix
Do not use document.domain as a way for an iframe to discover an unrelated parent’s domain. Its setter is deprecated, can weaken same-origin protections, and does not change every origin check. It also cannot be set in a sandboxed iframe and can be ineffective with origin-isolation features. MDN says: “Instead of using document.domain to facilitate cross-origin communication, you should use Window.postMessage to send an asynchronous message to the other origin.” Read MDN’s Document: domain property reference for the limits and deprecation details.
What sandboxing and ancestor frames change
An iframe’s sandbox settings can restrict scripts and assign the document a special origin that fails same-origin checks unless the relevant sandbox tokens are enabled. That can change whether the expected message-origin checks work as configured. Review the iframe’s actual attributes and deployment setup rather than assuming that a matching hostname is sufficient.
window.parent refers to the immediate parent, not necessarily the top-level page. Messaging can be designed for a particular parent-child pair, but there is no universal, reliable way for a child to discover every ancestor’s origin without their cooperation. Do not treat an incidental property or referrer as an authoritative substitute for a deliberate exchange.
Quick Recap
Quick decision guide
- You control the parent: define a message protocol and have the parent disclose only the required value.
- You control only the iframe: you can send a request to the parent, but you cannot force it to reply or read its origin directly.
- You need to read the parent DOM:
postMessage()does not grant DOM access; the parent must perform the needed operation or provide data explicitly. - You are considering
document.domain: avoid it for new designs and use validated messaging instead.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →
