Conversation
Both the bridge and turbo message handlers construct this one class, and it forwarded every WKScriptMessage to its delegate without ever asking which frame sent it. Any subframe a page embeds - a third-party ad, an OAuth widget, a video player - could post to window.webkit.messageHandlers.bridge or .turbo and be obeyed with the main document's authority: proposing a visit, supplying the HTML that becomes the document, or driving any registered bridge component. The forMainFrameOnly: true flag on the injected user scripts does not close this. It scopes where the injected JavaScript runs, not which frames may post to a handler, and messageHandlers is present in every frame regardless - a subframe can skip the wrapper and call postMessage with a hand-built body. WKScriptMessage carries frameInfo, which WebKit populates and the page cannot forge, so read isMainFrame from the platform instead of trusting anything the page supplies. The refused origin is logged so an app that was relying on a subframe message can see why it stopped arriving.
|
Implementation-only diff: dbc4fc0..54b3e6e — Context receipt — acceptance clause built to: "every legitimate bridge component still works; a foreign-origin subframe gets no bridge at all, with a log line saying why." Platform contract of record: Baseline: existing suite green on this range — 368 tests passed via |
1 participant
No description provided.