How Superintelligence Works | Agent Cross-Origin Messaging — postMessage Origins, Frame Identity and Verified Actions

Did you know that a webpage embedded in an iframe can send messages to the page around it without gaining direct access to the parent’s documents? Browsers support cross-origin communication through `window.postMessage`, a useful mechanism for embedded tools, school portals and AI-assisted forms. The danger comes when an application treats any incoming message as a trusted instruction. A reliable agent integration checks exactly which origin and window sent the event, validates the message schema and current task state, then independently verifies any resulting consequential action.

The practical method is to use exact target origins for outbound messages, compare trusted expected origins and source windows for inbound events, validate message types and payloads, distinguish a ready or accepted signal from actual completion, and bind any external action to the current user permission and resource. This guide works through an invented one-hundred-message laboratory and a forty-message school-portal transfer. Every number is fictional teaching data, not an eduKate security measurement or evidence that artificial superintelligence already exists.

This article extends How Super Intelligence Works. The CORS Decisions chapter covers which HTTP cross-origin responses a browser can expose to scripts, and Browser Automation covers finding and acting on current UI controls. Here the separate security boundary is an asynchronous message crossing from one browser window to another.

Choose a useful reading route

• Embedding an AI widget? Start with exact targetOrigin and event.origin checks.
• Handling iframe forms? Study source windows, message schemas and current user authorization.
• Learning Mathematics? Verify the 100-message and forty-message exercises.
• Debugging completion? Distinguish browser acknowledgements from saved backend effects.

Contents

• 1. postMessage bypasses one barrier in a controlled way
• 2. The targetOrigin on send is part of confidentiality
• 3. The receiver must check event.origin
• 4. Check event.source when the window identity matters
• 5. The payload still needs strict validation
• 6. CORS and postMessage control different surfaces
• 7. Frames can navigate during asynchronous work
• 8. Handshakes help establish an expected conversation
• 9. PostMessage does not provide business completion receipts
• 10. Do not let iframe messages bypass user consent
• 11. Iframe sandboxing adds separate restrictions
• 12. Cross-origin messages can carry confidential data
• 13. An original hundred-message validation laboratory
• 14. Count verified external actions separately
• 15. Changed-context exercise: forty embedded worksheet actions
• 16. Test navigation races and message confusion
• 17. Diagnose six distinct classes of failure
• 18. Operational monitoring without collecting every payload
• 19. A practical release checklist for agent-enabled pages
• Frequently asked questions
• Browser and security sources
• Related eduKate engineering guides

1. postMessage bypasses one barrier in a controlled way

The web’s same-origin policy normally restricts how scripts from unrelated origins access one another’s documents. The `window.postMessage` API deliberately enables a message to cross between Window objects when the sender has an appropriate window reference. MDN describes its use between a page and a popup or an embedded iframe. This permits useful integration without granting unrestricted DOM access.

An AI-enhanced school portal might embed a worksheet preview owned by another service. The parent page can ask the preview to scroll to a passage, while the preview can notify the parent of a user selection. The messages carry typed information, not automatic authority to publish a document or read private account data. The application must decide which message types it accepts.

A hostile or merely unrelated window may also be able to send an event if it has a reference to the target window. MDN explicitly cautions receivers to validate the origin and sometimes the source of every expected incoming message. A JSON object saying `approved:true` is not evidence that an authorised editor approved anything.

Separate the user task from transport. The model can suggest that the parent wants to attach a worksheet, but the trusted browser application must still identify the correct iframe and apply user and resource permissions. A valid cross-origin message may inform the interface without completing the backend task.

Return to contents or continue to The targetOrigin on send is part of confidentiality.

2. The targetOrigin on send is part of confidentiality

MDN’s postMessage documentation recommends specifying an exact `targetOrigin` when the destination is known, rather than using a wildcard. The browser compares scheme, hostname and port under origin rules. A wildcard accepts any destination origin and can disclose information if the target window navigates to an unexpected site before the message is delivered.

Consider an authorised parent page sending a draft preview identifier to an embedded editor. A specific destination such as the approved editor’s HTTPS origin limits delivery to that origin. A sender using `*` might disclose the identifier to a window that has navigated elsewhere. The model’s belief that the popup is still the correct editor cannot substitute for the browser’s current destination check.

Exact origin is not the same as an entire URL path. An origin contains the scheme, hostname and relevant port; `/editor/preview` is a path under that origin. A receiver may still need a task, document and audience check after origin validation because several applications can be hosted at the same origin. Do not treat one trusted origin as universal authority for every resource.

Some exceptional URLs have opaque origins and require special handling, as MDN notes for `data:` contexts. Such exceptions are not a reason to use wildcard targets for ordinary private school records. Prefer a normal approved HTTPS endpoint where exact origin can be enforced for sensitive messaging.

Return to contents or continue to The receiver must check event.origin.

3. The receiver must check event.origin

An incoming `message` event includes an `origin` attribute describing the sender’s origin at the time postMessage was invoked. A receiver can compare it against a configured exact allowlist for the intended integration. A loose suffix check may accept unrelated subdomains or maliciously similar hostnames. Use the browser’s structured origin value under a reviewed policy.

Do not rely on natural-language page titles such as ‘Official School Portal’ or fields inside `event.data` to identify the sender. Those values can be chosen by the sender. The browser-provided origin has different provenance from the payload, though the application still needs its own authorization and message-schema checks after confirming an expected sender.

MDN cautions that `event.origin` reflects the sender at the time the message was sent and may not equal the current origin of that window after navigation. This matters for asynchronous or delayed events. A later navigation cannot be assumed to preserve the original trusted context. Long-running controllers should bind messages to an active task, trusted source window and expected state.

An origin may be valid for one operation but not another. A public learning widget might be permitted to send a worksheet-selection event without being authorized to command a private email. Origin validation establishes the sender’s permitted transport context, not consent for the action represented by its data.

Return to contents or continue to Check event.source when the window identity matters.

4. Check event.source when the window identity matters

The `message` event can carry a `source` reference to the window that sent it. MDN recommends checking origin and, where relevant, source. An application expecting a reply from one specific popup should not accept the same message from another window merely because both belong to an allowed service origin.

Imagine two open editing windows for different school accounts. They may share the same origin, but one corresponds to a private Maths draft and the other a public Science page. A message saying Save from the wrong window can target the wrong document if the parent verifies origin but ignores the expected frame identity and task association.

A parent page can maintain a mapping from window reference to authorized workflow, pending request ID and intended document. It can accept only a known message type from that active window and then validate the payload. The model should not infer the mapping from a display title or the order in which frames appear on screen.

Window identity is not immutable authorization. A popup can navigate, the user can switch accounts and an approval can expire. Bind each message to current task and user state as well as the immediate browser sender checks. A stale window handle is not a grant to repeat a protected action indefinitely.

Return to contents or continue to The payload still needs strict validation.

5. The payload still needs strict validation

Even a message from a legitimate service may contain malformed or unexpectedly large data. The receiver should validate message type, expected fields, value types, lengths and allowed operations before using the content. A sender’s trusted origin does not mean every value is correct or entitled to become a backend command.

Use a small contract such as `type: preview_selected`, `request_id: …` and `document_id: …` rather than arbitrary text instructing the model what to do next. The document ID should then be checked against the authenticated user’s actual resource permission. A free-form string that contains SQL-like text or a URL is data to interpret under a specific safe tool, not new authority.

A payload such as `event.data.approved=true` may be suitable as an interface hint in an untrusted sandbox but not as the definitive record of a human’s publication approval. The protected approval service must establish who approved the exact draft and when. A valid message schema does not create a missing credential or user signature.

Handle unknown message types safely. A provider update might add a new status or send extra fields. A strict receiver can ignore unsupported optional fields under a deliberate compatibility policy or hold an unknown consequential action until reviewed. The model should not turn an unfamiliar event into Success just because its wording sounds positive.

Return to contents or continue to CORS and postMessage control different surfaces.

6. CORS and postMessage control different surfaces

CORS is an HTTP response-sharing mechanism that lets a server indicate which origins can read certain cross-origin fetch responses in the browser. postMessage is a direct message channel between Window objects. These facilities often appear in the same application, but setting a CORS header does not automatically authorize arbitrary window messages.

Likewise, receiving a message from an approved iframe does not grant that iframe unrestricted access to the parent page’s API responses. The browser’s same-origin and CORS enforcement continues to apply to relevant fetches. A design should state which channel carries what information, rather than use one security checklist to cover all cross-origin flows.

An agent might have access to a browser automation tool that can navigate and click through the interface. That does not change the postMessage receiver’s responsibility to validate `event.origin`, `event.source` and data. A model’s ability to see a popup on screen does not establish the trust level of a hidden message arriving asynchronously.

The companion CORS Decisions chapter explains preflight and credentialed response policies. This article’s security contract remains necessary even in an app that has all its CORS rules configured correctly.

Return to contents or continue to Frames can navigate during asynchronous work.

7. Frames can navigate during asynchronous work

An iframe or popup may be at one origin when the agent opens it and at another when the browser sends a later message. Navigation can happen through normal login redirects, user clicks, provider updates or an unexpected page. A cached assumption based on the original URL is not sufficient to establish the current destination for sensitive outbound data.

Use an exact target origin when sending messages to the intended window. On receiving an event, check the origin value provided by the browser at send time, the source window reference and the expected active request. This mitigates common navigation-related mistakes but does not prove the payload’s substantive facts are true.

A school portal may redirect a user through authentication before showing a worksheet preview. The parent can wait until the correct active editor is ready under its approved origin and task identity rather than broadcast a private document reference to every intermediate page. A race between navigation and messaging should result in a held or retried harmless handshake, not an unapproved backend send.

Time matters when requests expire. An approval may be valid when the popup opens and revoked before its result arrives. Current business authorization remains the execution gate. A delayed cross-origin response can accurately describe what the popup did earlier without authorizing a new action now.

Return to contents or continue to Handshakes help establish an expected conversation.

8. Handshakes help establish an expected conversation

A parent page and embedded widget can establish a request ID and an expected response type before exchanging useful data. The ID helps correlate an incoming event with a pending operation instead of accepting arbitrary unsolicited messages. It is not itself an identity credential, but it makes accidental cross-task association easier to detect.

Choose unpredictable or appropriately unique identifiers where replay or guessing matters under the application design. A simple sequential counter may support ordinary local correlation, but should not be presented as a secure authentication secret without a threat assessment. The browser origin and source checks, current user permissions and backend authorization remain separate controls.

After a valid response, mark the request completed under the message protocol so a repeated event does not trigger the same consequence twice. Some duplicated progress events may be harmless, while a command to publish, send or delete requires stable logical-operation idempotency and final-state verification. Message deduplication does not automatically deduplicate a provider-side write.

Do not expose entire signed file URLs or private documents merely to complete a handshake. A restricted document ID and safe preview state may suffice, with an authorized service fetching the actual content under current permission. The protocol should minimize data crossing between origins.

Return to contents or continue to PostMessage does not provide business completion receipts.

9. PostMessage does not provide business completion receipts

The JavaScript call to `postMessage` schedules delivery under browser event-loop behavior. MDN notes that the sending call itself cannot determine whether a receiving event handler later throws. Successfully invoking the API therefore does not prove the destination processed the request, let alone saved an article or sent a message.

A receiver might send an acknowledgement event, but that too is a browser-level statement whose meaning depends on the protocol. `accepted` could mean the iframe parsed a command, while `completed` might be only its own local state. For user-visible external actions, fetch a trustworthy target result from the actual backend.

Imagine a school editor iframe sending `draft_saved`. The parent page should check which draft ID and revision the backend stored before telling the user the document is safe. If the iframe merely updated its local textarea, the message may be useful progress but not a persistent artifact. Keep these statuses distinct.

A model can explain the state in friendly language without fabricating certainty. If the browser event arrived but the server result is missing, report that the action remains unverified rather than creating another post or claiming the user can download a file that does not exist.

Return to contents or continue to Do not let iframe messages bypass user consent.

10. Do not let iframe messages bypass user consent

A cross-origin widget might offer suggested actions such as Publish, Share or Delete. The user can see them and make a decision, but the application should not treat a widget message as a replacement for current authenticated approval. The widget origin might be trusted for UI state while the underlying user permission remains narrower.

An agent acting for a parent can prepare a school message in an iframe, then receive `send_requested` when the person presses a button. The backend still needs the actual intended recipient and current approval. A malicious or buggy widget generating the same event without user action must not gain an irreversible sending capability.

Different actions require different scope. Displaying a preview, selecting a source passage and publishing an article cannot share one blanket approval boolean. Use typed operations and resource IDs, and enforce least privilege at the service that will perform the external effect. A model’s generated narration cannot replace those checks.

Protect cancellation. If the user withdraws permission while a popup waits, a late `confirm` message should not resurrect the old request. The active task record should show that the grant no longer applies. A safe receiver can preserve historical evidence without starting a new protected action.

Return to contents or continue to Iframe sandboxing adds separate restrictions.

11. Iframe sandboxing adds separate restrictions

The HTML iframe sandbox attribute can constrain embedded content, such as scripts, same-origin treatment or navigation capabilities, depending on the tokens supplied. MDN warns that combining certain allowances in a same-origin embedded context can undermine intended isolation. The exact configuration should follow the embedded service’s legitimate needs rather than grant every token for convenience.

Sandbox attributes are not a replacement for postMessage origin and data validation. An iframe may still send a message through the supported interface under its permitted capabilities. The parent must decide whether that particular sender and payload are expected, not assume the word sandbox makes every event safe.

A school portal may need an embedded document preview but not popups or top-level navigation. Narrowing its sandbox capabilities can reduce unexpected effects. If a particular accessibility or editing feature requires another permission, review the actual consequence and test it instead of having the AI model remove sandbox restrictions whenever a widget complains.

Test the configuration in a browser. A sandbox setting that prevents required work can produce user frustration, while an overly broad one can expand the attack surface. Positive and negative controlled cases are needed to establish that the integration is both useful and bounded.

Return to contents or continue to Cross-origin messages can carry confidential data.

12. Cross-origin messages can carry confidential data

The application should decide which fields truly need to cross the boundary. A document-selection event can often carry an opaque source ID and version rather than a full learner record. Sending an entire private assessment to a third-party frame may be unnecessary even if that frame belongs to a known provider.

Use exact target origins and trusted recipient windows for sensitive messages. Avoid wildcard targets where a specific origin is available. Keep potential exposure through browser extensions, support screenshots, error logs and monitoring in mind. A direct message is not necessarily visible to the user, so the service’s data-flow policy matters.

Messages received from other origins should not be written unchanged into an agent’s long-term memory or tool logs. They can contain personal data, stale source citations or attacker-controlled instructions. Extract the necessary typed fields under a bounded policy and protect the remaining content as lower-trust source data.

The Sensitive Log Redaction chapter explains why routinely collecting entire raw payloads can create a second private-data repository. Event identity, expected origin and verified disposition may be enough for ordinary debugging.

Return to contents or continue to An original hundred-message validation laboratory.

13. An original hundred-message validation laboratory

Consider a fictional Cedar Portal receiving one hundred synthetic cross-window messages. Sixty-two match the expected sender origin, source window, schema and active request, and are safely processed under the permitted UI contract. Fifteen fail origin validation. Ten come from an unexpected source window. Eight have unsupported or malformed payloads, and five describe operations whose external results remain unverified.

The categories are mutually exclusive: 62 + 15 + 10 + 8 + 5 = 100. Validly processed messages are 62%; origin refusals 15%; source-window refusals 10%; schema refusals 8%; unresolved downstream effects 5%. These invented percentages are not measurements of browser attack prevalence or eduKate service quality.

The thirty-three refused messages can reflect correct protective decisions rather than app failure. An origin from an unrelated page or a malformed message should not become an agent instruction. The five unresolved effects require backend reconciliation; they should not be grouped with either a confirmed failure or a completed user task.

The unit is received messages, not distinct parents or final documents. One legitimate user task may exchange several handshake and progress messages before completing. Counting every valid message as a separate happy user would inflate service outcomes.

Return to contents or continue to Count verified external actions separately.

14. Count verified external actions separately

Suppose the sixty-two valid protocol messages include forty-eight harmless UI updates, ten valid requests to begin a backend check and four acknowledgements about already completed work. They still form sixty-two message dispositions, not sixty-two newly saved artifacts. A different ledger must inspect actual WordPress, storage or message-provider state.

An origin-valid callback might signal that a page rendered a file preview, while the user’s actual request was to download a readable worksheet. The browser event cannot certify successful transfer. Likewise, a Save click or accepted command can precede a server rejection. Keep protocol success and task success as independent measures.

Now imagine three of the five unknown downstream outcomes are confirmed complete through the original target IDs. Under the simplified event classification, verified protocol/related results can be reported separately, but the total number of received messages remains one hundred. A later evidence update should not invent three new messages or trigger duplicate writes.

Use the original task and operation ID across progress messages. A model that sees several accepted events may falsely conclude that several actions were carried out. Stable identities prevent confusing chatty interface traffic with meaningful educational work.

Cross-window disposition	Messages	Share	Meaning
Expected sender and valid event	62	62%	Protocol processing permitted
Origin check refused	15	15%	Untrusted origin
Unexpected source window refused	10	10%	Wrong popup or frame
Schema or type rejected	8	8%	Unsupported message
External outcome not verified	5	5%	Check backend receipt
All fictional messages	100	100%	Received-event denominator

Return to contents or continue to Changed-context exercise: forty embedded worksheet actions.

15. Changed-context exercise: forty embedded worksheet actions

Transfer the method to a fictional school page with forty iframe responses. Twenty-five are valid and tied to their intended active worksheet tasks. Six fail origin validation, four have the wrong source window, three fail schema checks and two have uncertain backend save state. Check 25 + 6 + 4 + 3 + 2 = 40.

Valid protocol messages are 62.5%, origin denials 15%, source-window denials 10%, schema denials 7.5% and unknown effects 5%. These figures teach classification, not actual security or learning outcomes. A protocol-valid event is still only one stage of the parent’s requested task.

Now the preview iframe navigates during login to a different origin. The parent should not send a private worksheet identifier with wildcard target merely to keep the workflow moving. After the widget returns to the expected origin and the active request is verified, a narrowly scoped message can proceed.

Change the approval too: the editor has revoked permission to publish while an iframe holds an old `approved` state. The backend must refuse the late publish command even when the browser origin, window reference and JSON schema all pass. This illustrates why communication authenticity and human authorization are separate gates.

Return to contents or continue to Test navigation races and message confusion.

16. Test navigation races and message confusion

Build an isolated browser test that creates a parent page, one intended iframe and a second unexpected window. Give the intended widget one exact allowed origin and register a pending task ID. An event from the correct origin but wrong window should be refused where source identity is part of the contract. A syntactically valid message from the wrong origin should also fail.

Simulate navigation before an outbound message. A sender using an exact target origin should not deliver sensitive data after the destination moves elsewhere. A wildcard target might deliver under a different condition, demonstrating why the stricter form matters. No real school records or live credentials are needed in this test.

Include a positive control where a legitimate preview selection works, and a negative control where a fake `publish_now` message cannot cause a backend write without current approval. The independent oracle should inspect the actual browser message and target service state, not accept the model’s narration that it chose correctly.

Test repeated messages and a lost acknowledgement. The receiver can safely ignore duplicate UI progress events while reconciling a consequential backend operation by its original identity. A model should not manufacture new operation IDs simply because it wants a second chance to make the interface say Done.

Return to contents or continue to Diagnose six distinct classes of failure.

17. Diagnose six distinct classes of failure

Failure one: the sender uses wildcard target origin and leaks a private message after navigation. Repair with an exact destination origin. Failure two: the receiver trusts a `sender` field inside payload rather than event.origin. Repair browser-provided origin validation. Failure three: a permitted origin sends from the wrong popup or iframe. Repair source-window and task association.

Failure four: an origin-valid sender supplies malformed or unexpected data that changes tool arguments. Repair typed schema checking and resource-level permission. Failure five: a successful postMessage is reported as a completed external save. Repair backend readback and truthful state labels. Failure six: a late approval message executes after the user cancels. Repair current cancellation and grant checks at the actual effect.

Do not solve all six by disabling every message. The integration should still serve legitimate source previews and user workflows. Independent positive tests establish that correct events arrive and are interpreted safely under expected identity. A safe system should be useful, not merely silent.

Keep a regression fixture for each defect. Browser updates, popup lifecycles and tool adapters can change relevant assumptions. The evidence should be actual event origin, source, payload disposition and trusted target state, not a model-generated statement that it followed best practices.

Return to contents or continue to Operational monitoring without collecting every payload.

18. Operational monitoring without collecting every payload

Record event type, expected origin identity, observed origin class, task reference and validation outcome under an appropriate privacy policy. Those fields often suffice to diagnose a source mismatch or unsupported message. Avoid logging entire private worksheet bodies, access tokens or temporary signed file links simply because a browser emitted them.

Repeated rejected events may indicate a misconfigured provider integration, navigation during login or unwanted activity. Investigate the mechanism before classifying every refusal as an attack. A legitimate school widget whose origin has changed may need a reviewed endpoint mapping, not a security policy removed by the AI agent.

Monitor timeouts and unknown backend effects separately from browser-message validity. A 100% origin-validation pass rate cannot prove that students received accurate worksheets or that WordPress posts were saved. Connect the protocol ledger to a verified user-task ledger through stable operation identity.

Provide a correction route for users. If an iframe reports success while the server never saved the intended file, the parent should be able to see the unresolved status and request appropriate help. A transparent status preserves trust better than an unexplained spinner or an invented completion claim.

Return to contents or continue to A practical release checklist for agent-enabled pages.

19. A practical release checklist for agent-enabled pages

Start with a precise description of the participating origins and windows. Define allowed outbound target origins, expected inbound source references, message types, payload schemas, valid user tasks and protected backend effects. Never treat a broad wildcard or free-form `approved` string as a substitute for this protocol contract.

Implement exact browser identity checks and data validation in application code. Ensure current user permissions, target resource and cancellation are enforced where any external effect occurs. Keep the user-visible workflow accessible and the iframe sandbox appropriately narrow. A model can recommend an action, but the browser and server implement the actual boundary.

Test ordinary communication, navigation changes, duplicate messages, wrong origins, wrong source windows, malformed payloads and uncertain backend acknowledgements. Use fictional documents in an isolated environment. Read back the saved target for consequential actions, and preserve an honest Unknown state when the provider cannot be checked.

The durable lesson is that cross-origin communication delivers information, not permission. A successful browser message can make an AI-supported interface responsive, while trust and completion still depend on the right sender, current user intent and independently verified resources.

Return to contents.

20. Same-origin trust is not a universal business permission

A service may host several school widgets beneath one origin. The browser’s origin check then establishes that a message came from that hosting origin, but does not decide which student’s worksheet or which publishing task it belongs to. A receiver should still verify active document identity, account and expected message type, not allow every widget on that domain to edit every record.

A practical protocol can pair the origin with a trusted window reference and a pending request ID created by the parent. The payload must match the declared task and permitted action. If the same service hosts a public preview and a private account editor, their messages may need different capabilities despite arriving from the same origin. Do not collapse these distinctions into a blanket Allow list.

The risk continues after navigation. A trusted popup can change account, switch resources or follow a new login flow. An old request ID should expire or be invalidated when its owner no longer controls the relevant task. The browser’s sender-origin value is a necessary check, not perpetual authority over every future window state.

A language model can explain why a message was refused, but a protected receiver should enforce the refusal before a tool action occurs. A confirmation prompt cannot repair an earlier leak of private data sent to the wrong origin. Identity and destination checks belong where messages are generated and processed.

Return to contents for the full route.

21. Design a message protocol with explicit lifecycle states

Define a small state machine for a school preview: Created, Ready, Request Sent, Acknowledged, Source Verified, Completed or Cancelled. These states describe different milestones. An iframe saying Ready means its interface initialized, not that a parent authorized publishing; an Acknowledged response means the widget received a command, not that WordPress completed a server write.

Give requests stable identities and bounded expiry, and define which response types are legal in each state. A late completion message after the user cancels can be retained as historical evidence without starting new external work. An unexpected `publish_now` message during a preview-only state should be refused even when the origin and schema are valid.

Keep the protocol’s error states meaningful. Invalid Origin, Wrong Source Window, Unsupported Message Type, Expired Request and Backend Result Unknown require different next actions. A universal error string like Failed can drive unsafe retries or conceal a site integration regression. A controlled state table helps engineers diagnose the correct layer.

After a permitted action, the parent should verify the real target through a trusted API or saved-resource readback. The event protocol can carry the canonical post ID or file reference needed for reconciliation, but a generated description of completion cannot replace that check. A small precise protocol is more useful than unlimited free-form instructions.

Return to contents for the full route.

22. Message security must coexist with accessibility

Embedded educational widgets often show their status inside the iframe while parents interact with controls outside it. A message can notify the parent page that selection changed, but a visually updated label does not automatically announce the change to a screen-reader user. The host should present progress and errors accessibly under its own user-interface rules rather than rely solely on invisible cross-window events.

Focus management after dialogs and navigation matters as well. An iframe may request that the parent open a review panel, but moving focus or accepting a destructive confirmation should follow actual user intent and predictable interface behaviour. A model deciding that the easiest route is to click a confirmation is not equivalent to accessible informed consent.

Security checks and accessibility are complementary. A receiver that rejects an unauthorized message can explain the refusal in a user-facing region without exposing a restricted filename or record. An authorized action can announce when a saved artifact is truly verified rather than when a browser request was merely dispatched.

Test with fictional documents using keyboard navigation, visible status and an independent target-state check. The positive path should be usable by an actual person, while the negative path should make clear why an attempted action is unavailable. A perfectly secure message channel that no parent can understand is not an adequate educational workflow.

Return to contents for the full route.

23. A changed navigation sequence can be tested reproducibly

Build a fictional parent portal with an approved editor iframe and a separate untrusted preview frame. Create a pending request for a Mathematics worksheet, then navigate the approved iframe through a test login page before it responds. A message to the old origin should not disclose the worksheet reference if the receiving window now has a different destination. The test harness should inspect actual delivered events.

Next, send a validly formatted response from the unexpected preview window. Origin alone may match if both frames are hosted on the same service, but the active task expects the editor window. The protected receiver should reject the wrong source. Then send a response from the right window with an invalid document ID and verify that resource authorization rejects it as well.

Finally, allow the correct selection event and separately simulate a backend save timeout. The receiver may have a valid protocol message while the artifact result remains Unknown. Reconcile the original operation under the current user permission before another send. This demonstrates three different observations: who sent the event, what it contained and what the server actually did.

Keep the fixture under version control with test origins, task IDs and expected outcomes, not real parent names or active file tokens. After a browser or widget update, replay these cases to detect regressions. One passing screenshot from a normal flow cannot establish resilience against navigation races or message-confusion defects.

Return to contents for the full route.

• 20. Same-origin trust is not a universal business permission
• 21. Design a message protocol with explicit lifecycle states
• 22. Message security must coexist with accessibility
• 23. A changed navigation sequence can be tested reproducibly

Frequently asked questions

Does postMessage ignore the same-origin policy?

It provides a controlled message channel between Window objects without granting full cross-origin DOM access.

Why avoid a wildcard targetOrigin?

A navigated recipient window could receive sensitive data from an unexpected origin; exact targets are safer when known.

Is event.origin the same as the iframe’s current location?

It reflects the sender origin at message send time, and need not equal that window’s later location.

Are event.origin and event.source interchangeable?

No. Origin identifies a security origin; source can help identify the particular expected window.

Does a valid browser message authorize publication?

No. The protected backend still needs the current user grant, exact resource and version.

Does postMessage returning normally prove the receiver saved data?

No. The call is not a business completion receipt; verify actual server or storage state.

Browser and security sources

Primary web-platform references checked 25 October 2026. Cedar Portal, message counts, sender identities and transfer outcomes are fictional teaching cases.

• MDN — Window.postMessage: Target origins, event.origin, source windows, navigation races and secure messaging.
• WHATWG HTML — Web Messaging: Normative cross-document messaging mechanics and security requirements.
• MDN — iframe: Sandbox options and embedded context behavior.
• MDN — Same-Origin Policy: Origin identity and restrictions on cross-site document access.
• OWASP HTML5 Security Cheat Sheet: Cross-origin message validation and client-side security considerations.
• OWASP Authorization Cheat Sheet: Backend action authorization separate from client-side messages.

Related eduKate engineering guides

Continue with Super Intelligence curriculum; CORS Decisions; Browser Automation; Session Cookies; Agent Feature Flags; Sensitive Log Redaction; Gold Standard of Education. Browser messages are transport evidence; current user permission and actual target state determine the effect.