Windows, iframes & postMessage

Several windows, one careful page

A web app is not always one document in one tab. It may open a popup for sign-in, embed a payment widget in an iframe, preview untrusted content in a sandbox, or receive a message from a map, video player, or account portal. Those pieces are all browsing contexts: separate places where a document lives.

The important idea is simple: a reference is not permission. Your page may hold a reference to another window, but the browser still decides what can be read, changed, or messaged. That decision starts with the same-origin policy from the CORS lesson: scheme, host, and port must match before one document can freely inspect another.

This lesson builds the safe habits: open popups only when the user asked, treat cross-origin frames as opaque, send messages with a narrow target, validate messages on arrival, and protect sensitive pages from being framed in the first place.

A popup is a top-level browsing context: usually a new tab or window. JavaScript opens one with window.open(url, target, features). In most browsers, a popup is allowed when that call happens directly during a user gesture, such as a button click. Calls from timers, page load, or background code are often blocked, and window.open returns null.

The safest popup code has a boring shape: call it from a click, check for null, do only what the browser allows, then clean up. The lab opens about:blank, which inherits the opener’s origin, writes a tiny document, reads closed, and closes it. It also shows that noopener cuts the opener link and returns null.

1button.addEventListener("click", () => {2  const popup = window.open("about:blank", "lessonPopup", "width=360,height=240");3  if (!popup) return "blocked";4  popup.document.write("<h1>Hello from the opener</h1>");5  console.log(popup.closed);6  popup.close();7});8 9const safePopup = window.open("about:blank", "_blank", "noopener");10console.log(safePopup);

Iframes and same-origin access

An iframe embeds another document inside the current page. Same-origin iframes are powerful: the parent can read their DOM, call functions, and share origin-scoped storage. Cross-origin iframes are intentionally narrow. The parent can keep a window reference, but most reads throw a security error.

That narrow list is still useful. Cross-origin references can usually use postMessage, focus, blur, close, read simple properties such as closed, length, and frames, and assign location in limited ways. They cannot read the other page’s DOM, cookies, storage, variables, or full URL.

When two windows are not allowed to read each other directly, they can still cooperate by sending messages. The sender calls otherWindow.postMessage(data, targetOrigin). Later, the receiver gets a message event. That event has data, origin, and source.

Opaque sandboxed frames are the awkward case. Without allow-same-origin, their origin is exposed to message handlers as the string "null". You cannot name that as a normal URL origin when sending, so * is required for delivery. That makes the receiving checks even more important.

1const frame = document.querySelector("iframe");2const trustedWindow = frame.contentWindow;3 4window.addEventListener("message", (event) => {5  if (event.origin !== "null") return;6  if (event.source !== trustedWindow) return;7  show("accepted", event.data);8});9 10trustedWindow.postMessage({ kind: "ping" }, "*");

The live lab uses two sandboxed srcdoc frames. Both have origin "null", but only one is the stored trusted contentWindow. The stranger can copy the data shape, but it cannot pass the event.source check.

1const trustedOrigin = "null";Run2const trustedFrame = "lesson-frame";3 4function receiveMessage(event) {5  const originOK = event.origin === trustedOrigin;6  const sourceOK = event.source === trustedFrame;7  if (!originOK || !sourceOK) return "rejected";8  return "accepted: " + event.data.kind;9}10 11receiveMessage(incomingEvent);

Message data is structured-cloned: plain objects are copied into the other window, not shared. Functions and DOM nodes cannot be cloned. The next lesson goes deep on structured cloning, transfer, and channels; here the key habit is validation before action.

The sandbox attribute starts an iframe with many powers removed. Then tokens add specific powers back. A bare sandbox blocks scripts, forms, popups, modals, and same-origin treatment. Tokens such as allow-scripts, allow-forms, allow-popups, allow-modals, and allow-same-origin each open one door.

1// The parent rebuilds the iframe with selected tokens.2frame.sandbox = "allow-scripts allow-forms";3frame.srcdoc = predefinedHtml;4 5// Inside predefinedHtml:6parent.postMessage({7  scriptRan: true,8  origin: self.origin,9  canSubmitForms: sandbox.contains("allow-forms"),10  canOpenPopups: sandbox.contains("allow-popups"),11  canShowModals: sandbox.contains("allow-modals")12}, "*");

This is why the CORS sandbox demo and the postMessage lab both use predefined srcdoc and sandbox="allow-scripts". The code can run, but the frame stays opaque and all communication goes through a small message protocol.

Clickjacking, also called UI redressing, is not about reading another page. It is about tricking a user into clicking it. The attacker frames a sensitive page, puts a decoy on top, and lines up the real button underneath the fake one.

1<iframe title="fake bank" sandbox srcdoc="...bank button..."></iframe>2<div class="decoy">3  <p>Looks like a video player.</p>4  <button>Play</button>5</div>6 7/* Lower the decoy opacity to reveal the hidden frame underneath. */

This public lesson page does not send those protective headers because there is no sensitive action to protect. An admin site, account settings page, or payment approval page should. In our stack, the admin site sends X-Frame-Options: DENY; public lessons do not need to block learners from embedding harmless content.

Where you will use this

These APIs show up in ordinary product work:

• OAuth sign-in. Open a provider popup from a click, use noopener when appropriate, and receive a final success message from a controlled redirect page.
• Payment widgets. Embed a cross-origin iframe, send it setup data with a specific targetOrigin, and accept only messages from its known origin and source.
• CMS previews. Render preview HTML in a sandboxed iframe so it cannot mutate the editor page. Use messages for height, navigation, or selection events.
• Interactive docs. Run risky demos in sandboxed srcdoc frames and report results back through validated messages.

Common misconceptions

Your score counts first tries. Read the explanations for wrong answers; they are written like mini code reviews.

Key takeaways

• Popups should open from user gestures; handle null, closed, and noopener.
• Same-origin iframes are readable; cross-origin iframe references are narrow but can use postMessage.
• postMessage data is structured-cloned and delivered later as a message event.
• Validate event.origin, event.source, and the data shape before acting.
• Sandbox tokens add back powers one by one; avoid risky combinations for same-origin untrusted content.
• Clickjacking is stopped by server headers such as X-Frame-Options and CSP frame-ancestors.

Up next: Messaging & structured cloning.