---
{
  "title": "Secure cross-window messaging",
  "summary": "Cross-window messaging lets browser documents exchange data through postMessage.",
  "topic": "offensive",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    7
  ],
  "aliases": [],
  "sources": [
    {
      "title": "OWASP: HTML5 Security",
      "url": "https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

Cross-window messaging lets browser documents exchange data through postMessage. The receiver must validate the sender's origin and message structure, while the sender should constrain the intended destination. A message from another window is untrusted input unless a specific relationship establishes otherwise.

## A practical example

A checkout frame accepts a small set of messages only from its approved parent origin. It checks the message schema and never inserts received content into an unsafe HTML sink or treats a message as proof that payment succeeded.

## What to check

Use exact intended target origins, validate the event origin and expected source where applicable, and define a narrow message schema. Test unexpected senders and malformed or repeated messages.

## A common pitfall

Checking that a hostname contains a familiar substring is not reliable origin validation. An origin includes scheme, host, and port, and similarity is not equality.

## Think it through

Why specify a target origin when sending sensitive data?

**Answer:** It reduces the chance that a window navigated elsewhere receives a message intended for the trusted document.

## An origin is only part of the conversation

A fictional booking page embeds a trusted calendar frame. The frame sends a selected date to its parent, and the parent replies with a booking identifier. Both sides need to know which window they expect, which origin is allowed, and which message shapes are valid. A familiar-looking field such as 'success' is not evidence that a transaction occurred.

Navigation can change the document occupying a window. Sending sensitive information to a wildcard destination ignores that change. An exact target origin gives the browser a condition for delivery, while receiver checks decide whether an arriving event belongs to the expected conversation. Where the workflow requires it, compare the event source with the expected window reference as well.

Message content still needs validation after origin checks. A trusted partner can have a bug or send a message intended for another stage of the flow. Define permitted message types and fields, reject unsupported operations, and handle duplicates without repeating a sensitive action. Correlating a response with the relevant request helps prevent accidental mixing of concurrent interactions.

## Design a small messaging protocol

For a local exercise, define two messages for the calendar example: date-selected and booking-displayed. List the exact fields and expected sender for each. Add an unknown message type, an invalid date, and a repeated message. State which cases are rejected and which can safely be ignored.

Keep message handlers away from unsafe HTML insertion and arbitrary code evaluation. A cross-window message is a data interface, much like a network API, even though it arrives inside a browser. Testing the sender, receiver, and application effect separately makes the trust relationship easier to review and maintain.

## Related concepts

- [[cors]]
- [[dom-based-xss]]
- [[input-validation]]