Please bear with me, I have only some web development experience. In the window.postmessage() documentation syntax is shown for listening for the event caused by postmessage() on the listening page. It is explicitly stated for security reasons that when the event listener is triggered, event.origin should be check to ensure it es from an expected host. Typically done in the fashion:

if ( event.origin == somehostname) {}

Where I get confused is why a malicious user can't just pause the code using a breakpoint and modify the some hostname value. This same thing probably applies for the postmessage() call itsself as well for the target origin parameter. How does this provide any "security" when someone could just go edit the string value before it ever happens?

Please bear with me, I have only some web development experience. In the window.postmessage() documentation syntax is shown for listening for the event caused by postmessage() on the listening page. It is explicitly stated for security reasons that when the event listener is triggered, event.origin should be check to ensure it es from an expected host. Typically done in the fashion:

if ( event.origin == somehostname.) {}

Where I get confused is why a malicious user can't just pause the code using a breakpoint and modify the some hostname. value. This same thing probably applies for the postmessage() call itsself as well for the target origin parameter. How does this provide any "security" when someone could just go edit the string value before it ever happens?

• javascript

• It’s not secure against the person running the JavaScript (nothing client-side is). It’s filtering out messages from any other site that person might have open. For other types of interactions, the same-origin policy is what protects websites (origins) from each other, but postMessage specifically exists to bypass that so you have to check yourself. – Ry- ♦ Commented Jun 14, 2019 at 19:51

2 Answers 2

Your theoretical malicious user already has full access to the client-side of both websites. They don't need postMessage to access the data from either of them.

The Same Origin Policy is designed to stop a malicious website from accessing data from a different website using the credentials of the user of the browser (who has been tricked into visiting the malicious website).

postMessage can limit which origins are allowed to read the messages it sends, so if a website used it to send a message containing confidential information, it can mark the posted message as being for some-trusted-website. which would prevent the malicious website from reading the message.

A "malicious" user could, certainly, make the client-side code do most anything they want, such as leaking information [that they already have access to] to another website, via window.postMessage or just by copying it and pasting it into an e-mail.

In your follow-up ment, you describe "we create a malicious website ready to receive some confidential info" as the threat model. That's a different thing entirely.

Yes, any website that's window.postMessage on sensitive data ought to do at least one of the following to be secure:

1. Check the Referer header to make sure that your parent is a trusted domain

2. Set targetOrigin to restrict recipients to those intended