Same-origin parent postMessage broker for dynamic signing from opaque-origin creative iframes

[aram356]

Context

PR #956 removes allow-same-origin from CREATIVE_SANDBOX_TOKENS, so creatives rendered via srcdoc run in an opaque origin. Any fetch from that context is cross-origin with Origin: null; the JSON POST to /first-party/sign preflights and fails, so signProxyUrl now bails out early (returns null) when window.origin === 'null'.

The consequence is that the dynamic-src guard's runtime proxying is disabled inside sandboxed creative iframes: runtime-injected <img>/<iframe> elements fall back to loading their original third-party URLs directly (dynamic_src_guard.ts). The sandbox still isolates them from the publisher origin, but the first-party proxying/privacy benefit is lost for dynamically inserted resources.

Proposed design

A narrowly validated same-origin parent postMessage broker:

• The parent-page tsjs core registers a message listener that accepts sign requests only from iframes it created (validate event.source against tracked creative iframe contentWindows, never trust event.origin — it is null for these frames).
• Request payload is a strict shape ({type, id, url}); the parent performs the same-origin POST /first-party/sign itself and posts back {type, id, href} to the requesting frame.
• The creative runtime's signProxyUrl uses the broker when window.origin === 'null', with a timeout falling back to the current unsigned behavior.
• A real-browser regression test covering a mutated rewritten click and a dynamic resource sign round-trip from a sandboxed srcdoc iframe.

References

• PR Make creative sanitization opt-in and restore creative iframe origin isolation #956 review threads on proxy_sign.ts (opaque-origin CORS) and render.ts (sandbox tokens).