What are the concrete risks of calling `window.postMessage(data, '*')` with a wildcard `targetOrigin`, and when is `'*'` genuinely acceptable?

## What targetOrigin actually does `otherWindow.postMessage(message, targetOrigin)` takes a mandatory second argument. It is not documentation and not a hint: at delivery time the user agent compares `targetOrigin` against the origin of the document currently loaded in `otherWindow`. If they differ, the message is discarded — no exception thrown to the sender, no `message` event fired at the receiver. The argument exists purely to protect the **sender's confidentiality**. Three forms are legal: - an explicit serialized origin, `'https://widget.example.com'` — scheme, host and port only, never a path; - `'/'` — deliver only if the receiving window's origin is identical to the sender's; - `'*'` — deliver unconditionally. The same values apply in the options form, `postMessage(message, { targetOrigin, transfer })`. ## The failure mode: the window you meant is not the window that is there The reason `'*'` is dangerous is that your handle to another window is stable while the *document* inside it is not. A `WindowProxy` obtained from `window.open()` or `iframe.contentWindow` keeps pointing at the same browsing context after it navigates to a completely different site. Realistic sequences: ```js const popup = window.open('https://partner.example/authorize?...'); // ...partner redirects to an identity provider, or to an attacker-supplied // return_to URL, before your code fires. popup.postMessage({ accessToken }, '*'); // lands on whatever origin is loaded now ``` Or the embedded case: you post configuration containing a user identifier to `frame.contentWindow` with `'*'`, and another script on your own page — an analytics tag, a tag-manager snippet — has rewritten that frame's `src` to a third party. You cannot see it, and the browser will not stop you. There is also a subtler variant. Timing matters because the origin is evaluated when the message is delivered, not when you decided to send it. Any redirect that lands between your check and your call is a window of exposure that an explicit `targetOrigin` closes for free. ## Why "it's just convenience" is the wrong framing The usual defence is that the receiver validates `event.origin` anyway, so a wildcard is harmless. That confuses the two directions of the trust boundary. The receiver's `event.origin` check protects the *receiver* from messages it should ignore. `targetOrigin` protects the *sender* from handing data to a page it never intended to talk to. Both checks are needed; neither substitutes for the other. A wildcard send to a hostile page is a completed disclosure regardless of what any well-behaved receiver would have done. ## The legitimate uses `'*'` is acceptable when the payload contains nothing you would mind publishing to an arbitrary origin, and you genuinely do not know the peer's origin. The canonical case is a third-party widget that is embedded on thousands of customer domains: the framed widget cannot enumerate the origins that embed it, so its first message to `window.parent` — a bare `{type:'ready', version:'3'}` — goes out with `'*'`. The pattern that keeps this safe is to treat the wildcard as a bootstrap only: 1. Send a non-secret hello with `'*'`. 2. The peer replies; the browser stamps `event.origin` on that reply, and page script cannot forge it. 3. Validate `event.origin` against your allowlist, keep it, and use it as `targetOrigin` for every subsequent message — or hand over a `MessagePort` at that point so later traffic bypasses the shared bus entirely. For same-origin conversations, `'/'` is strictly better than either `'*'` or a hardcoded origin string: it survives moving between staging, preview and production hostnames while still refusing to deliver to a cross-origin document. ## What targetOrigin does not do It authenticates an **origin**, not code, and not a user. If the target origin is compromised — an XSS on that host, a hijacked subdomain — the message is delivered to the attacker's script exactly as the browser is designed to do. It also says nothing about which *frame* on that origin receives it; if the origin runs several frames, whichever window handle you used gets the message. Finally, it does not encrypt or sign anything. Cross-window messages stay inside the browser process, so there is no wire exposure, but the payload is fully readable by any script running in the receiving document. Treat `postMessage` as a channel whose only access control is the origin pair, and size what you put on it accordingly.