postmessage-security

Tests window.postMessage listeners for missing or weak origin checks and proves exploitable sinks.

7|4|Updated Jun 22, 2026
One-click install
npx skills add https://github.com/dbx0/skills --skill postmessage-security-dbx0
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: postmessage-security
Source: https://github.com/dbx0/skills/tree/main/skills/web-appsec/discovery/postmessage-security
Command: npx skills add https://github.com/dbx0/skills --skill postmessage-security-dbx0

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Embedded widgets, payment iframes, and cross-origin integrations often register window.postMessage listeners with missing or weak origin checks, turning them into data-exfiltration primitives. This Skill provides a repeatable methodology to find those listeners, classify their sinks, bypass flawed origin checks, and prove real impact instead of reporting theoretical findings. ## Core Features & Use Cases - Listener Sweep and Triage: Grep first-party JavaScript bundles for addEventListener("message") and onmessage handlers while excluding non-exploitable MessageChannel polyfills and Web Worker handlers. - Sink Classification and Origin-Check Analysis: Trace event.data flows into tokenization URLs, encryption keys, storage writes, navigation, and DOM sinks, then evaluate origin checks for regex suffix flaws, .includes() bypasses, and coercion issues. - End-to-End Proof via CDP: Drive a real browser from a file:// page or window.open() popup to demonstrate the sink fires, accounting for storage-partitioning differences between iframes and popups. - Use Case: During an assessment of an embedded payment iframe, you discover its origin check accepts any domain matching a .com.br suffix regex, letting an attacker-controlled page supply the tokenization URL and RSA key to exfiltrate PAN/CVV data. ## Quick Start Audit the target site's JavaScript for postMessage listeners with weak origin checks and prove exploitability using a browser-driven proof of concept.

Frequently Asked Questions about postmessage-security

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I test postMessage listeners for missing origin checks?

Grep the first-party JavaScript bundle for addEventListener("message") and onmessage handlers, excluding MessageChannel polyfills and Web Worker handlers. Then classify each listener by whether event.data reaches a sensitive sink like a tokenization URL, encryption key, storage write, or navigation.

What origin check patterns are bypassable in postMessage handlers?

Regex suffix checks like /\.(com|net)\.br$/ accept attacker domains such as evil.com.br, and .includes() checks are bypassed by trustedDomain.attacker.com. Only strict === comparison against a hardcoded origin string is considered safe.

How do I prove a postMessage vulnerability end to end?

Drive a real browser via CDP or Playwright from a file:// page, which reports a null origin, or from a window.open() popup on an attacker-controlled domain. Post the crafted message and capture evidence the sink fired, such as an exfiltration request or a changed encryption key.

Does iframe storage partitioning affect postMessage exploitation?

Yes, third-party iframes writing to localStorage are neutralized by modern browser storage partitioning, landing in an isolated partition. Use window.open() popups instead, which are not partitioned, and report the iframe variant as reduced impact.

When is a postMessage listener not a reportable finding?

A listener that only updates UI-local state with no downstream sensitive effect is not a finding. Reporting the mere existence of a listener without a missing or weak origin check plus a proven sensitive sink is a common mistake.