Reject a lookalike origin before handling a host message

A playable embedded in a host may receive messages from more than one source. This fixture tests an exact origin boundary rather than accepting any address containing a trusted-looking word.

This edition is a laboratory fixture. Node and the companion HTML page execute the authored functions against synthetic cases. No physical device panel was run, no ad network reviewed the build, and no campaign result is inferred from a passing test.

What the documentation actually supplies

MDN: message origin is the governing reference for the browser primitive. MDN describes postMessage as a controlled cross-origin communication mechanism. Its security guidance requires validating message origin and, where appropriate, source and message structure before acting. The fixture policy around that primitive is ours.

The failure the fixture isolates

The laboratory's permitted origin is an example.invalid host. The fixed branch requires exact origin equality and the expected message type. The broken branch accepts origins containing the string host. Inputs are inert records; no cross-window messages or external actions are sent.

The broken branch is retained so a producer can see the exact mistake, not only the repaired output.

All 3 fixed-branch cases matched the spec when executed in Node on 19 September 2026.

What a pass does not prove

Passing this check establishes one part of message validation. A real handler also needs to verify the expected source window and the complete payload shape. An origin alone is not a schema, and a valid message type does not make arbitrary additional data safe or meaningful.

Untested cells in this edition: physical devices, host SDKs, network packaging limits, store-opening callbacks, and campaign performance. Those remain empty on purpose.

Next check on a real build

Create a narrow list of host events and document what each can change. Exercise the handler with unrelated origins, malformed data and an unexpected source window. Keep unknown messages inert. This is a defensive integration fixture, not a test of any named advertising SDK or evidence that its message protocol uses these values.

Open the runnable fixture to re-execute the cases in a browser. Download the case record to keep inputs, expectations and limits with a QA ticket.

Background in the archive: Playable ad device testing matrix and Playable spec sheet before you build. Those guides describe practice; they are not a substitute for this fixture and this check does not recertify their every claim.