How is this not a hole in postMessage security?

Question

Suppose I'm using the postMessage() API to communicate between frames on different domains. The standard security check in the receiving frame is to verify the origin property of the message event like:

if ( messageEvent.origin !== "http://www.mydomain.com" ) {
    console.log( "Message received from unexpected domain!" );
    return;
}

But what if someone used the debugger/inspector in their browser to set the source for the sending frame to a malicious URL that included Javascript to send messages that requested sensitive data or did other bad things. Then couldn't they edit the code above in the browser's inspector and change the origin being checked to the malicious URL? Now, they initiate a message event in the sending frame that has the malicious code and the receiving frame happily accepts the malicious message . . .

Why is this not a huge security hole for postMessage?

Have you tried recreating this "security hole"? If yes then did you succeed or is this only a theory? — jsalonen, Jun 05 '14 at 20:20
Chrome allows you to edit Javascript, but apparently ignores the edited code, and still runs the originally loaded code, so no, I can't duplicate this theoretical security hole in Chrome. But couldn't somebody write their own "black hat" browser that DID let the user edit the Javascript that was run on a page? And then this would be an issue? — mrverdantgreen, Jun 05 '14 at 21:05

score 0 · Answer 1 · answered Jun 05 '14 at 22:44

Why is this not a huge security hole for postMessage?

Because the security policy is to prevent communication with unknown domains. When you receive a message, you test the origin to be a domain which you trust (in case of mydomain.com, because you control it).

If that trusted domain suddenly sends malicious messages, you're screwed. By design.

Also, never trust the user. And if he should decide to do wrongful things to the page that is shown to him (e.g. by use of developer tools), that is his own fault. You only need to ensure that such cannot affect other users.

How is this not a hole in postMessage security?

1 Answers1