Proposal: Improve support for multiple target origins for Window#postMessage

[eliasm307]

Problem Overview

The current standard for posting cross-domain messages (ie https://html.spec.whatwg.org/multipage/web-messaging.html#posting-messages) specifies that only a single targetOrigin can be specified, and for security reasons it is strongly recommended to provide an exact target origin rather than * (see https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage#security_concerns).

However a practical application could be required to operate in different environments when embedded so to get around the single targetOrigin limitation the application could send the same message to multiple target origins, ie:

["https://origin1.com", "https://origin2.com", "https://origin3.com"].forEach(targetOrigin => {
        window.parent.postMessage(`Target: ${targetOrigin}`, {targetOrigin});
})

Such a strategy means only one of the messages can possibly be sent (as the actual origin can only match one of the options at most), and for the other origins the standard says "the message is discarded".

However the current interpretation of this is to log this as an error which can seem like there is something wrong with the application when it is functioning normally, ie:

For some applications that generate many cross-domain messages this can produce a significant number of error messages which can be confusing if one of the origin options actually matches and the application is functioning normally.

Proposals

Specify a message with a mismatched target origin is not an error

The existing workaround for multiple targetOrigins could be supported by the standard specifying that it is not an error implicitly or the options for postMessage could include a new property which can be used to define whether an origin mismatch should be treated as an error (where the default is yes to support existing behaviour)

Support specifying multiple target origins

The standard could update to allow targetOrigin to define multiple origins e.g. as a comma separated list e.g.

{
  targetOrigin: "https://origin1.com, https://origin2.com, https://origin3.com"
}

However this means the standard would also need to define the format for this list and how to handle malformed lists e.g.

• Are spaces allowed?
• What should happen in this case ", ,* ,"?
• Are trailing commas allowed
• etc

Or as an array for less ambiguity:

{
  targetOrigin: ["https://origin1.com", "https://origin2.com", "https://origin3.com"]
}

Where the same rules when processing the existing single target origin would apply to every item of the array.

With multiple target origins the standard could then specify that the message produces an error only if the target window does not match any of the provided target origins

[annevk]

Is there evidence that this is a pattern websites use in the wild? Somewhat frequently?

Why wouldn't they know the target origin? (Perhaps they initiate the conversation?)

[eliasm307]

I don't have examples from the wild however I have seen threads like this while I was researching options for my use case https://stackoverflow.com/questions/35939798/specifying-multiple-targetorigin-uris-in-postmessage and it's concerning that because of the lack of multiple target origin support the top answer is actually advocating for using "*" which makes the application less secure.

For my case I am developing an application where a client can embed it in an iframe in different environments then listen for certain events/notifications from the iframe.

Because of the limitations and the fact browsers show this as an error I'm also leaning towards using "*" as there aren't a lot of alternatives

[annevk]

Thanks, such threads are valuable for making a case so if there's more of them please do list them. JavaScript libraries that help with the pattern as well.

[eliasm307]

Hi, related to this also found this thread with a comment that suggests another workaround is posting fake messages with a custom origin. However, I haven't tried to see if it actually works (especially cross origin).

In this case it's a workaround to a limitation with a framework but I think it is related to the base limitation of only being able to specify one target origin so frameworks need to also impose those limitations on users

cypress-io/cypress#6429 (comment)