Lion Cipher Lab

Exploit and fix a cross-origin postMessage flaw (web messaging) in your own lab

Why it matters

`window.postMessage` is how a page talks to an iframe or pop-up on another origin — payment widgets, chat bubbles, SSO buttons, analytics beacons and third-party embeds all lean on it. The Same-Origin Policy deliberately does NOT block these messages, which means the code that receives them is the entire trust boundary. A listener that acts on every message it gets — and worse, drops the payload into `innerHTML` — is a cross-origin hole an attacker triggers just by loading your widget in a frame they control. This is a real, common finding (its own OWASP WSTG test, WSTG-CLNT-11, and CWE-346,…

What you'll learn

Steps in this lab

  1. What web messaging is, and where the trust boundary really sits
  2. Make two origins on one machine (no hosts-file editing needed)
  3. Build the vulnerable widget (the receiver that trusts everyone)
  4. Build the legitimate app that embeds the widget
  5. Start the trusted server and confirm the widget works
  6. Build the attacker page on the second origin
  7. Fire the attack from a second server and watch it pop
  8. Name the root cause precisely (CWE-346 + an HTML sink)
  9. Fix #1 — check event.origin against an exact allowlist
  10. Fix #2 — validate the message shape and use a safe sink
  11. Fix #3 — send with an explicit targetOrigin, never "*"
  12. Re-run the attack and prove it's dead
  13. The edge cases that bite people
  14. Find these in your own code
  15. What you did — and the rule to carry forward

Open the full interactive lab →