2

When using postMessage it's important to define a targetOrigin to ensure we don't leak data to other sites.

It's equally important to check the origin when receiving a message to prevent other sites from triggering our scripts.

But, if we're just expecting to do this on our own domain, is there anything wrong with:

targetWindow.postMessage({message}, window.origin);

--

window.addEventListener("message", e => {
  if (e.origin == window.origin){
    //Trigger something
  }
});
2
  • 1
    Note, this was originally posted on Stack Overflow, but it was suggested that I post here for a more appropriate audience! stackoverflow.com/questions/64128018/…
    – Jamie G
    Nov 24, 2020 at 23:03
  • I agree this should be here. You are clearly asking for the security considerations and not for (just) a code solution.
    – LvB
    Nov 25, 2020 at 1:34

1 Answer 1

1

targetWindow.postMessage({message}, window.origin);

So line transmits the windows origin (e.a. The page domain loaded) As the origin data for the post message. This is fine.

window.addEventListener("message", e => { if (e.origin == window.origin){ //Trigger something } });

This would check that the message received is from the same origin as this window. This is slightly more problematic, if someone hosted this code on same other domain it would still work. (If that’s not a concern than it’s fine). A more secure strategy would be to replace the window.origin with a const ORIGIN = “<domain>; and if( e.origin === ORIGIN). This would make it impossible to redefine the origin mod processing of the javascript (or at least after the const) and would make the check do a type check and value check. (Instead of a typebended value check)

Source

9
  • Hey, many thanks for this response, sorry for slow reply. Can you explain why you describe the latter as problematic? It's not the done thing to start all JS scripts with if(window.origin !== "mydomain.com") throw "Problematic error :/"; What makes these listeners risky, where my other js code isn't?
    – Jamie G
    Dec 17, 2020 at 9:53
  • Basically your code will react to all messages send to it. From any source. Without any validation. That’s slightly problematic imho.
    – LvB
    Dec 17, 2020 at 9:58
  • As I understand it, it will react to any message sent to it that claims to be from the same domain. I don't understand why hard coding the domain changes anything here?
    – Jamie G
    Dec 17, 2020 at 10:31
  • Well. Read up on XSS and other similar problems as to why. But “hard” code in the domain to prevent someone from Chargeing it. Especially when you consider add-ons you simply can’t assume this check will work as you intended.
    – LvB
    Dec 17, 2020 at 12:51
  • Thanks LvB, I know a fair bit about various methods of XSS but still can't see why a hardcoded domain would make a difference. Can you either elaborate or direct me to somewhere that does? Sorry if I'm being pedantic, but the point of the question was to either get solid reasons why this wasn't a good idea, or if no solid evidence could be given then I was going to assume that it's safe to use.
    – Jamie G
    Dec 18, 2020 at 0:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .