Event-Source Hijacking on a "Trusted" Iframe

Checking e.source === iframe.contentWindow without checking e.origin only proves which window object sent the message, not what origin currently controls that window.

Why It Works

• The WindowProxy stays the same across navigation, so navigating the trusted frame to your content lets you send messages the parent still trusts.

Vulnerable Pattern

• Parent pages that trust one embedded iframe by source-object equality alone.

Exploit Flow

1. Keep the same WindowProxy but navigate the iframe to content you control (or otherwise hijack it).
2. Once your code runs in that frame, send a message the parent now accepts as trusted.

Variations

• Redirect chains, intermediate same-window navigation, or open-redirect abuse inside the originally trusted frame.

Common Blockers

• Tight origin checks, iframe sandboxing, or no way to navigate the frame while preserving useful state.

PoC Sketch

// 1) navigate the trusted iframe to an attacker-controlled same-window target
// 2) then:
iframe.contentWindow.postMessage({html:"<img src=x onerror=alert(1)>"}, "*");

Good Situations To Use It

• The parent validates e.source but not e.origin.
• You can navigate the trusted frame.
• The message handler renders HTML/commands.

Sources

• fcsc2026/web/10_fast_fishers