A booking widget may need to resize its frame, but that is not a reason to accept arbitrary messages or unrestricted top-level navigation. Before commissioning an iframe integration, decide the exact capabilities, origins and message shapes required.
Primary evidence and claim boundaries
MDN describes iframe sandbox capability tokens and warns about same-origin allow-scripts plus allow-same-origin. Primary reference · Read 17 October 2026.
For postMessage, MDN advises exact target origins and validation of sender identity and received syntax. Primary reference · Read 17 October 2026.
Filled acceptance example
Synthetic teaching scenario, not a client case, provider integration test or business result. Scroll the example table on narrow screens.
| Synthetic incoming message | Contract check | Result |
|---|---|---|
| Origin https://booking.example.test; correct frame; {type:resize,height:640} | Exact origin + source + integer height in 200–1200 | Accept bounded resize |
| Origin https://booking.example.test.attacker.test | Suffix resembles vendor; exact origin differs | Reject |
| Correct origin; height:-1 or URL payload | Message shape/range outside contract | Reject; do not execute content |
| Correct origin; message from another frame | Source is not expected window | Reject |
Practical handover procedure
- List necessary capabilities with the vendor and security owner. Prefer a separate trusted origin and review each sandbox exception; no token combination is a universal safe recipe.
- Define a small typed protocol for resize or completion hints. Keep personal data and executable HTML out; a completion message must not itself authorise payment or fulfilment.
- In isolated authorised pages, exercise wrong origin, wrong frame, malformed payload and valid payload. Verify the fallback link if the embed cannot load.
Interpret the outcome
Only the first row satisfies the proposed resize contract. The200–1200 interval is a synthetic UI choice, not a browser standard or a security guarantee. Origin checks and sandboxing solve different parts of trust; neither removes the need for server-side authorisation.
Acceptance decision
Require documented capabilities, exact origins, validated protocol and a functional fallback. A screenshot of the embedded page cannot establish those controls.
Limits and unverified work
Defensive synthetic contract; no external frame was messaged, embedded or given permissions. Browser/vendor compatibility and security approval are still required for a real integration.
Download the filled bilingual acceptance record — Contains these inputs, steps, expectations and limits. This is a teaching record, not an executable integration.