Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: ef2c0c95908c02bc3720b120d29e4172877f0bf5
https://github.com/WebKit/WebKit/commit/ef2c0c95908c02bc3720b120d29e4172877f0bf5
Author: Ruthvik Konda <[email protected]>
Date: 2026-10-10 (Sat, 10 Oct 2026)
Changed paths:
M Source/WebKit/UIProcess/WebFrameProxy.cpp
M Source/WebKit/UIProcess/WebFrameProxy.h
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm
Log Message:
-----------
REGRESSION(322953@main): [Site Isolation] UI process crashes when a
cross-site iframe is served with Content-Security-Policy:
upgrade-insecure-requests
https://bugs.webkit.org/show_bug.cgi?id=326805
rdar://189511645
Reviewed by Adrian Taylor and Alex Christensen.
322953@main started checking that the frame's process speaks for the domain of
each origin in
WebFrameProxy's DidChangeCSPOriginsThatUpgradeInsecureNavigations message. It
asked process(),
which is the process the frame has committed to.
A cross-site iframe whose response carries Content-Security-Policy:
upgrade-insecure-requests
applies that policy in DocumentWriter::begin, before its load commits, and its
provisional process
sends this message then. At that point process() is still the frame's previous
process, which does
not speak for the iframe's domain, so the check failed. A popup's main frame
fails the same way when
it loads a cross-site document with that header, because its WebFrameProxy is
reused across the
process swap and keeps its previous process until commit. With site isolation
on, a failed message
check crashes the UI process. The failure was also blamed on the frame's
process connection rather
than on the connection that sent the message.
Validate the origins against the process that sent the message, and blame its
connection, as
DidCommitLoadForFrame already does for the same set. Then apply the set only if
the sender is the
process that hosts the frame. A provisional frame's set reaches the UI process
again in
DidCommitLoadForFrame, which reads the set at commit and validates it against
the sender, so
dropping the earlier copy loses nothing. This is also stricter than before: a
process that does not
host the frame can no longer replace the frame's set, even with origins it
speaks for.
To make validating against the sender the default, WebFrameProxy's
EXTRACT_WITH_MESSAGE_CHECK now
blames the connection the message arrived on, and callers pass
ProcessSpeaksForDomain { connection },
as ProxyingPageAgent does. Its only other caller, setAppBadge, now validates
its origin against the
sender too. setAppBadge is sent from script after commit, so it could only fail
the same way if a
frame's previous process sent it after the frame committed in another process;
there is no test for
that race, and the badging tests still pass.
This also fixes
imported/w3c/web-platform-tests/upgrade-insecure-requests/link-upgrade.sub.https.html,
which has crashed on the site isolation bots since 322953@main.
Test: Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm
* Source/WebKit/UIProcess/WebFrameProxy.cpp:
(WebKit::WebFrameProxy::setAppBadge):
(WebKit::WebFrameProxy::didChangeCSPOriginsThatUpgradeInsecureNavigations):
* Source/WebKit/UIProcess/WebFrameProxy.h:
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/SiteIsolation.mm:
(TestWebKitAPI::TEST(SiteIsolation,
CrossSiteIframeWithUpgradeInsecureRequestsHeader)):
(TestWebKitAPI::TEST(SiteIsolation,
NavigationAfterWindowOpenWithUpgradeInsecureRequestsHeader)):
Canonical link: https://commits.webkit.org/323364@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
