[whatwg] A potential slight security enhancement to postMessage

[Jeff Walden]

The original message never showed up, sadly, so the threading's going to be a bit wrong here, unfortunately.


> Currently postMessage is great for sending authenticated messages
> between frames. The receiver knows exactly where each message came
> from. However, it doesn't provide any confidentiality guarantees. When
> you're posting a message to a window, you have no way of knowing who
> is listening on the other end, because the same-origin policy prevents
> you from reading the domain and URI of that window. The window may
> have been showing a page loaded from foo.com the last time you
> received a message from it, but it might be displaying content from
> bar.com now; if you send it a message, you don't whether the message
> will be received by foo.com or bar.com.

I noted in IRC discussion that postMessage being sync allows a challenge-response protocol to be safely used here, and you can determine the target's identification using domain/uri on the responding message; counterresponse was that's somewhat complicated.  Fair enough; I'm not sure if super-security is the main use case for this feature or not (lightweight collaboration seems more likely to me, but I don't really know), so I'm hesitant to comment too much on it.


> The postMessage API could be extended to provide confidentiality by
> adding some optional arguments:
> 
> void postMessage(in DOMString message, [optional] in DOMString domain,
> [optional] in DOMString uri);
> 
> If "domain" or "uri" are specified, the browser would only deliver the
> message if the recipient's location matches the specified domain and/or
> URI. (Being able to specify the URI allows sites to differentiate
> between http and https URIs.)

This seems reasonable enough.


> For privacy, postMessage should be designed not to reveal the domain
> or URI of the receiving window, so if there is a mismatch, the message
> should be silently dropped.

Silent dropping is definitely good.


> Providing the domain and URI for replies should be easy since these
> values are already parameters of the event.

True -- problem is requiring people use them, since they're not forced to do so now.

Jeff