Validating postMessage Origins Against Untrusted Frames

A security review flagged your message listener: it reads event.data and acts on it without establishing who sent it, which means any page that can obtain a reference to your window can drive that code path.

Triage: Establish What the Listener Accepts

1. Find every addEventListener('message', …) in the codebase, including inside vendor bundles you inject.
2. For each, check whether event.origin is compared before event.data is read. Reading first and validating later is the same as not validating.
3. Check whether the comparison uses equality or a substring test. startsWith and includes are both bypassable.
4. From the console of an unrelated page, post a message to your frame and observe whether the handler runs.

• Every message listener enumerated, including third-party ones.
• For each, established whether the origin is checked before the payload is used.
• Any substring comparison noted as a finding in its own right.
• Confirmed experimentally whether an arbitrary sender is accepted.

Root Cause: Delivery Is Unauthenticated by Design

postMessage is a transport, not a channel. Any script holding a reference to a window — a parent, an opener, a frame it created — may post to it, and the browser delivers the message without asserting anything about the sender beyond stamping event.origin and event.source on the event. Those two fields are the entire authentication mechanism, and they only work if the receiving code consults them.

Two shortcuts account for most real failures. The first is checking the origin with a substring test, which is bypassable in more ways than it looks: origin.includes('vendor.com') accepts https://vendor.com.attacker.example and https://evil-vendor.com alike, and startsWith('https://vendor') accepts https://vendor-attacker.example. Only exact equality against a known string is safe.

The second is checking the origin and not the source. An origin check establishes where the message came from; it does not establish which frame, and if any other frame on the page is loaded from the same origin — a second instance of the same widget, or a page the vendor navigated to — it passes the origin check while being a window you never intended to trust. Comparing event.source against the specific contentWindow you created closes that gap, and it is one line.

Resolution: A Guarded Listener

// bridge.js — the whole security surface of the embed lives here.
const EXPECTED_ORIGIN = 'https://widget.vendor.example';   // exact, no trailing slash
const ALLOWED_TYPES = new Set(['resize', 'ready', 'submit']);

export function attachBridge(iframe, handlers) {
  function onMessage(event) {
    // 1 — exact origin. Substring tests are bypassable; equality is not.
    if (event.origin !== EXPECTED_ORIGIN) return;

    // 2 — the specific window we created, not merely one from that origin.
    if (event.source !== iframe.contentWindow) return;

    // 3 — shape. Anything unrecognised is dropped, not partially handled.
    const msg = event.data;
    if (!msg || typeof msg !== 'object') return;
    if (!ALLOWED_TYPES.has(msg.type)) return;

    // 4 — values. A well-formed message can still carry a hostile one.
    if (msg.type === 'resize') {
      const h = Number(msg.height);
      if (!Number.isFinite(h) || h < 0 || h > 2000) return;
      handlers.resize(h);
      return;
    }
    handlers[msg.type]?.(msg);
  }

  window.addEventListener('message', onMessage);
  return () => window.removeEventListener('message', onMessage);
}

The outbound half needs the same discipline in mirror image: always name a specific targetOrigin rather than '*', because a wildcard delivers your payload to whatever document currently occupies the frame — which may not be the vendor you embedded if they redirected.

iframe.contentWindow.postMessage({ type: 'config', theme }, EXPECTED_ORIGIN);

Verification: Post From Somewhere Else

From the console of an unrelated origin, obtain a reference to your window and post a well-formed message. The handler must not run. Then post a message from the correct origin but from a second frame loaded from that origin — it must also not run, which is the check that distinguishes an origin-only guard from a complete one.

Vendor Listeners You Did Not Write

Auditing your own listeners is the easy half. A vendor SDK you inject frequently registers its own, with its own validation or none, and it is running in your document with access to everything yours can reach.

You cannot fix their code, but you can bound it. A vendor whose messaging is untrustworthy is an argument for moving the vendor into a sandboxed frame, where its listener lives in a separate origin and can be reached only through a channel you mediate. That converts an unauditable listener in your realm into an auditable one at a boundary you control.

Where that is not practical, at least enumerate them. Wrapping addEventListener early in the page to log every message registration tells you how many exist and which scripts registered them, which is more than most teams know — and the number is usually higher than expected, because tag managers, chat widgets and payment SDKs all register their own.

Why the Source Check Is the One People Skip

Of the four checks, the origin comparison is well known and the source comparison is not, which is worth dwelling on because the gap it leaves is not theoretical.

Consider a page embedding two instances of the same vendor widget — a common arrangement for a comparison view, or a page with a widget in the body and another in a modal. Both frames are loaded from the same origin, so both pass an origin-only check, and a message from one is indistinguishable from a message from the other. A resize instruction meant for the modal resizes the inline instance; a submission from one is attributed to the other.

The more serious version involves a frame that has navigated. A vendor frame that redirects to a different page on the same origin still satisfies the origin check while running entirely different code, and a page on a vendor’s domain that accepts user content — a preview, a sandbox, a documentation playground — becomes a way to reach your listener through a frame you legitimately embedded.

Comparing event.source against the exact contentWindow you created closes both. It costs one line and one reference held in a closure, and it turns “a message from this origin” into “a message from this frame”, which is what you actually meant.

Common Pitfalls

• Substring origin checks. includes, startsWith and regular expressions with unanchored patterns are all bypassable by a hostile hostname.

• Origin without source. Passes for any frame from that origin, including a second instance of the same widget.

• Using '*' as targetOrigin. Delivers your payload to whatever document currently occupies the frame.

• Validating after acting. Reading event.data into application state before the checks run means the checks are decoration.

• Holding the frame reference loosely. The source check needs the exact contentWindow for the element currently in the document. Re-reading it from a stale element reference after a re-render compares against a window that no longer exists.

Frequently Asked Questions

Related

• Cross-Domain Communication via postMessage
• Preventing Third-Party Scripts from Accessing the Window Object
• Building Secure Iframes for Third-Party Widgets

Up: Cross-Domain Communication via postMessage