How do I install the Web Postmessage skill?

Run npx skillmds@latest add noorqureshi/web-postmessage in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Web Postmessage safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Web Postmessage?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Web Postmessage free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Web Postmessage?

NoorQureshi (@noorqureshi) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Web Postmessage by noorqureshi — Agent Skill

Name: Web Postmessage
Author: NoorQureshi

Web Postmessage

Exploit insecure cross-window messaging (`window.postMessage`) — handlers that trust `event.data` without checking `event.origin`, leading to XSS, token theft, or state change. Load when the app uses iframes/popups/SSO widgets, on "postMessage", or when JS registers a `message` listener. Signals: `addEventListener("message", ...)`, embedded third-party frames, SSO/login popups.

NoorQureshi 603c32d 2.5 KB Updated Sep 17, 2026

File contents

postMessage abuse

When it applies

The target sends or receives postMessage between windows/iframes (SSO, payment widgets, chat, embeds). A receiver that doesn't validate the sender's origin will act on a message from your page.

Why it works

postMessage is cross-origin by design; safety depends entirely on the receiver checking event.origin and the sender setting a specific targetOrigin. Miss the origin check and any site can drive the handler; use targetOrigin="*" and any embedder can read the message. Then it's just a matter of what the handler does with event.data — often innerHTML, eval, location, or a relayed token.

Method

Find listeners: grep the JS for addEventListener("message" / onmessage; note the sink each handler feeds (innerHTML, eval, document.write, location, another postMessage).
Check the origin guard: no check, or a weak one — origin.indexOf("trusted")>-1, origin.endsWith("site.com") (matches site.com.evil), a loose regex — is exploitable.
Drive the sink (XSS): host a page that open()s or <iframe>s the target and postMessage()s a payload the handler writes to a DOM sink → script execution.
Steal data (leak): if the target sends messages with targetOrigin="*" (tokens, PII), embed it and read them in your message listener.
Bypass a bad check: register your attacker origin to satisfy the substring/regex flaw (trusted.attacker.com, attackertrusted.com).

Gotchas

event.origin (the sender) is the thing to validate — not event.source and not the URL bar.
Sandboxed iframes and X-Frame-Options/CSP frame-ancestors may stop framing — use a popup (window.open) instead.
Some handlers require a specific data shape/handshake — replay the legit message first, then mutate.

Verify success

A message from your attacker page reaches a dangerous sink (script executes / navigation happens) or you read a secret the target broadcast — reproducible from an external origin.

References

PortSwigger DOM-based / postMessage; MDN Window.postMessage security notes.

---name: web-postmessagedescription: Exploit insecure cross-window messaging (`window.postMessage`) — handlers that trust `event.data` without checking `event.origin`, leading to XSS, token theft, or state change. Load when the app uses iframes/popups/SSO widgets, on "postMessage", or when JS registers a `message` listener. Signals: `addEventListener("message", ...)`, embedded third-party frames, SSO/login popups.---# postMessage abuse## When it appliesThe target sends or receives `postMessage` between windows/iframes (SSO, payment widgets, chat,embeds). A receiver that doesn't validate the sender's origin will act on a message from *your*page.## Why it works`postMessage` is cross-origin by design; safety depends entirely on the receiver checking`event.origin` and the sender setting a specific `targetOrigin`. Miss the origin check and any sitecan drive the handler; use `targetOrigin="*"` and any embedder can read the message. Then it's justa matter of what the handler does with `event.data` — often `innerHTML`, `eval`, `location`, or arelayed token.## Method1. **Find listeners**: grep the JS for `addEventListener("message"` / `onmessage`; note the sink each handler feeds (`innerHTML`, `eval`, `document.write`, `location`, another `postMessage`).2. **Check the origin guard**: no check, or a weak one — `origin.indexOf("trusted")>-1`, `origin.endsWith("site.com")` (matches `site.com.evil`), a loose regex — is exploitable.3. **Drive the sink (XSS)**: host a page that `open()`s or `<iframe>`s the target and `postMessage()`s a payload the handler writes to a DOM sink → script execution.4. **Steal data (leak)**: if the target *sends* messages with `targetOrigin="*"` (tokens, PII), embed it and read them in your `message` listener.5. **Bypass a bad check**: register your attacker origin to satisfy the substring/regex flaw (`trusted.attacker.com`, `attackertrusted.com`).## Gotchas- `event.origin` (the sender) is the thing to validate — not `event.source` and not the URL bar.- Sandboxed iframes and `X-Frame-Options`/CSP `frame-ancestors` may stop framing — use a popup (`window.open`) instead.- Some handlers require a specific `data` shape/handshake — replay the legit message first, then mutate.## Verify successA message from your attacker page reaches a dangerous sink (script executes / navigation happens) oryou read a secret the target broadcast — reproducible from an external origin.## ReferencesPortSwigger DOM-based / postMessage; MDN Window.postMessage security notes.

Frequently asked questions