JS - How to securely use window.postMessage when the sender domain is unknown

Question

I would like to create a secure postMessage connection (origin safe), with an Iframe that is created at runtime.

Current state: I have a script, that generates an iframe with a specific domain (domain.b.com in the example below). I want that iframe to receive messages only from the parent domain (the page that included my script). Since the parent domain is unknown at runtime, I'm thinking of a "Handshake" process as described and illustrated below:

1. Wait for Iframe to be loaded.
2. Send postMessage from the parent domain with it's origin.
3. Set the allowed origin to be the 1st received origin

Edit: More Info:

1. On my server I have a whitelist domains (for example domain.a.com, any.domain.com, domain.b.com)
2. My Goal is to integrate with some of my clients (for example domain.a.com , domain.b.com)
3. Once integrated I want to prevent hackers injecting Iframes that can listen to sensitive information over postMessage
4. I want to avoid checking the whitelist, I prefer to give some acessToken, but not sure what is the right flow.

Example 1:

---

Example 2:

Is that the right way to implement it?

Answer 1

As mentioned here, you should not expect the parent's origin to be sent to you in postMessage's parameter. Instead:

If you do expect to receive messages from other sites, always verify the sender's identity using the origin and possibly source properties. Any window (including, for example, http://evil.example.com) can send a message to any other window, and you have no guarantees that an unknown sender will not send malicious messages. Having verified identity, however, you still should always verify the syntax of the received message. Otherwise, a security hole in the site you trusted to send only trusted messages could then open a cross-site scripting hole in your site.

And once you have the main frame's URI in your iframe, you can verify its authorization with a simple AJAX call to the server. In my point of view, a server call is inevitable and one way or another you will make such a call.

There are other ways to know who is including your iframe but they are not relying on postMessage. For instance if you are using PHP, you can check $_SERVER['HTTP_REFERER'] to see who is requesting your iframe even before it is sent to the browser. Yet there are ways to referrer spoofing as well.

If your application requires a solid bullet proof solution then server to server communication is your way. In this scenario, each client of yours has a username and password and the web server who is going to serve the main page should ask for a one time pass token from the web server who is serving the iframe (this is a server to server communication). And then use the token in the iframe's URL to be sent back to the server generated it. Here's a step by step of this scenario:

1. End user asks for the URL http://customer.com/main.php.

2. While main.php is executing and populating the response, it also connects to http://you_website.com/generate_token.php?username=cutomer1&password=123 and gets a one time pass token token1.

3. The response is returned to the browser containing an iframe with URL http://your_website.com/iframe.php?token=token1.

4. In iframe.php you verify the token1 to see if it is valid, and , at the same time, you are authenticating the requester without actually asking for his username and/or password (since you know who you have generated the token for).

Such tokens are usually deleted once used (one time pass) and they also usually come with an expiration data. But that's up to you and your application.