Introduction to PostMessage Vulnerabilities

Published by Harshdeep Singh, Security Testing and Assurance on 12 June 2025

Introduction

In the dynamic landscape of web application security, the PostMessage API has been used extensively for facilitating cross-origin communication between websites. However, this blog post sheds light on the potential vulnerabilities associated with PostMessage, urging developers and cyber security professionals to exercise caution.

This post emphasises the importance of carefully using event listeners for message events and advises against the use of wildcard (*) target origin with PostMessage. Furthermore, constant verification of the origin helps guard against unauthorised entities and thus protect against PostMessage based vulnerabilities.

Details

What is PostMessage?

The window.postMessage() method safely enables cross-origin communication between Window objects, e.g. between a page and a pop-up that it spawned, or between a page and an iframe embedded within it. This method provides a way to circumvent the restrictions implemented by Same Origin Policy (SOP).

How does it bypass the SOP?

SOP is a security mechanism implemented in all modern browsers, which prevents origin webpage’s JS from accessing/modifying the DOM of a website with a different origin which is usually embedded in an iframe or opened as a new window. The following examples help demonstrate how SOP works:

This code above simply creates an iframe and appends the contents from two files. The subsequent sections outline the respective contents of these files:

In this scenario, accessing content from local storage is possible within the context of the first code snippet, as it operates within the same domain. Conversely, attempting the same action with the second code snippet would fail, attributable to differing domains. This exemplifies the mechanics of the SOP.

Figure 1: How SOP works example.

This restriction by the SOP can be bypassed through the utilisation of the PostMessage functionality. This bypass is caused by a misconfiguration in the second code snippet due to the absence of an origin check.

Figure 2: No origin check when listening for message events.

This allows an adversary to bypass SOP using PostMessage, which in this case allows the retrieval of an ID in the local storage from a cross-origin domain.

Figure 3: Cross origin data retrieval via unsafe PostMessage handling.

Further impact

Let us understand what an adversary can do if the above-mentioned code was discovered in the wild. As seen in Figure 4, if a particular message type is set then the current window location is changed to the attacker specified input:

Figure 4: Further dangers of unsafe PostMessage handling.

This can be exploited easily with the following message, which could lead to Cross-Site Scripting vulnerability:

Figure 5: Cross-site Scripting via PostMessage.

Real world example 

During a web application test, CyberCX came across client-side JavaScript code in a legacy system. The page embedded a frame in a modal dialog box, which used the PostMessage API to communicate with the embedding page when the process was completed. 

The handler for these messages, however, did not validate the origin of the message. Here is a simplified version of the handler which was used as part of the JavaScript code for the web application:

This handler will navigate to an arbitrary URL in response to a correctly constructed message. By sending a message from a different page or domain, an adversary can pass a JavaScript URI, causing the contained code to execute by the receiving page (Cross Site Scripting). 

This was exploited in a Proof of Concept (PoC) page as an example. The embedded page waits for a click on a button, this allows a pop up to be opened, then the following JavaScript is triggered to achieve Cross Site Scripting (XSS):

The five second delay is required as it takes some time for the window’s even handler to be registered.

Detection

The most obvious way to detect PostMessage vulnerabilities is by reading JavaScript code. It is not always possible to easily detect this vulnerability as it requires tracing the execution flow to perform a successful attack. There are several open-source tools available currently, that can aid in detection of these vulnerable code flows: 

1. Using postMessage-tracker browser extension: This Chrome extension monitors PostMessage listeners by showing you an indicator about the number of listeners in the current window.
2. Using Dom Invader: This is a browser based tool that comes within burp’s built-in browser and can be used to test for various DOM based XSS vulnerabilities.
3. Using Domloggerpp: A browser extension that allows you to monitor, intercept, and debug JavaScript sinks based on customizable configurations. 
4. Using postMessage Detector Burp Extension: This extension passively looks for PostMessage related issues within Burp itself.

Mitigation

1. The application should always verify the sender’s identity using the origin.
2. Do not utilise a wildcard (*) target origin when sending or receiving messages, instead use the expected target origin with the PostMessage. This will help protect against DOM based vulnerabilities and malicious websites from stealing sensitive information. 
3. If it is not expected to receive any messages from other websites, then do not add any event listeners for message events. This would completely prevent any PostMessage related vulnerabilities. 

Summary 

In conclusion, this blog post has shed light on the consequences of PostMessage based vulnerabilities, which could lead to various other vulnerabilities like Cross Site Scripting (XSS) and information disclosure.

While PostMessage does open the door to seamless cross-origin communication, it is important to implement best practices to mitigate potential vulnerabilities and ensure a robust defence against evolving cyber threats.

Learn more about our Security Testing and Assurance team