Resources · 116
postMessage: verify origin, window and requested command
Define an iframe or popup messaging contract that rejects unexpected senders, payloads and operation states.
· 2 min
What this guide helps achieve
- Define peers and message types
- Validate before creating an effect
- Test navigation and out-of-contract events
Quick check
- Origin, window, type and minimal payload contract.
- Validation sequence and rejection without business effects.
- Rejection matrix and listener cleanup.
Step-by-step method
- 01
Define peers and message types
List exact approved origins, expected window reference and useful message types. Use a precise targetOrigin for exchanges carrying sensitive data. An origin includes scheme, host and port; searching for a substring in a domain name does not validate a peer.
Origin, window, type and minimal payload contract.
- 02
Validate before creating an effect
On receipt, compare event.origin and, for this window integration, event.source with the expected reference. Then validate schema, permitted values and operation state. Treat content as data without eval or HTML injection. An approved origin does not replace server authorization for a sensitive operation.
Validation sequence and rejection without business effects.
- 03
Test navigation and out-of-contract events
Test a lookalike domain, different port, another same-origin window, invalid fields and messages after closure. Remove unused listeners and invalidate completed exchanges. Ensure replies use an already approved origin even when the window has navigated.
Rejection matrix and listener cleanup.
Acceptance case to reproduce
Fictional example: these inputs describe no customer or observed result.
View case inputs
{
"allowed_origin": "https://widget.example",
"observed_origin": "https://widget.example",
"expected_window": "active_iframe",
"observed_window": "another_window",
"payload_schema_valid": true,
"expected": "reject_without_effect"
}Expected decision
Fictional example: the sender origin is approved https://widget.example, but event.source is another window. The contract requires the active iframe window: reject the message without issuing a command.
Your acceptance workbook
Record observations against this guide’s criteria. A record is not certification.
The workbook does not save automatically. Export before leaving.
Filters do not limit exports. Actions include issues and unreviewed criteria.
Import replaces current observations after your confirmation.
Management indicators
| Indicator | What it measures | First action |
|---|---|---|
| Unexpected cases rejected | Negative cases rejected without effects / executed negative cases | Record origin, window and state per case |
| Approved exchanges completed | Expected scenarios completed / expected scenarios tested | Separate message receipt from confirmed effect |
Common pitfalls
Frequently asked questions
Is checking event.origin enough to accept a command?
No. Also check expected window, payload structure and message state. The server must still verify permission for the requested action.
Official references
References consulted: . The method and worksheet propose checks to adapt to your context; they do not constitute certification.
Continue exploring
Related analysis
