Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 874b11286861f277dc660f09801778933052228a
https://github.com/WebKit/WebKit/commit/874b11286861f277dc660f09801778933052228a
Author: Anthony Tarbinian <[email protected]>
Date: 2026-06-15 (Mon, 15 Jun 2026)
Changed paths:
M LayoutTests/platform/mac-site-isolation/TestExpectations
M Source/WebKit/WebProcess/WebCoreSupport/WebLocalFrameLoaderClient.cpp
Log Message:
-----------
[Site Isolation] Storage access isn't revoked when an iframe navigates itself
cross-origin
https://bugs.webkit.org/show_bug.cgi?id=316853
rdar://179286611
Reviewed by Matthew Finkel.
When an iframe wants to access storage APIs it needs to be granted "storage
access".
This can be granted via something like a user gesture.
Importantly for this bug, storage access should be revoked when an iframe
navigates itself
to a cross-origin site.
The iframe's "storage access" is normally revoked after a cross-origin check in
WebLocalFrameLoaderClient::dispatchWillChangeDocument.
However, with site isolation, a cross-origin navigation ends up committing the
load
in a new process and calling
WebLocalFrameLoaderClient::dispatchWillChangeDocument.
It performs the origin check and calls removeStorageAccess as expected, however
this new process never held storage access to begin with.
The issue arises when the navigation involves a redirect. Take for example when
a localhost iframe navigates to 127.0.0.1 which gets redirected back to
localhost:
1. Navigate localhost -> 127.0.0.1
- localhost process has storage access.
- This cross-origin navigation spawns up a new process for 127.0.0.1
- WebLocalFrameLoaderClient::dispatchWillChangeDocument tries to
remove storage access in the 127.0.0.1 process since it fails
the cross-origin check
- !! The 127.0.0.1 process never had storage access so nothing changes
2. Redirect 127.0.0.1 -> localhost
- The navigation re-uses the localhost process
- WebLocalFrameLoaderClient::dispatchWillChangeDocument performs the
cross-origin check and sees that the the document's current URL
is the same as the new URL and it will NOT removeStorageAccess
3. The result is that storage access survives after an iframe
undergoes a cross-origin navigation
This patch introduces a fix which removes storage access for cross-origin
navigations
right at the source process, when the navigation starts.
In WebLocalFrameLoaderClient::dispatchDecidePolicyForNavigationAction, when an
iframe
is navigating itself to a cross-origin site, we sever the storage access right
there.
This way storage access is gone regardless of wherever the redirect ends up.
This is what the Storage Access API spec mentions
(https://privacycg.github.io/storage-access/)
"we limit the impact of a 'storage-access' permission grant to only give
access to
unpartitioned data to the nested Document that called
requestStorageAccess() and only
until the nested Document navigates across an origin boundary."
This fixes
http/tests/storageAccess/request-and-grant-access-then-navigate-cross-site-should-not-have-access.https.html
with site isolation enabled.
* LayoutTests/platform/mac-site-isolation/TestExpectations:
* Source/WebKit/WebProcess/WebCoreSupport/WebLocalFrameLoaderClient.cpp:
(WebKit::WebLocalFrameLoaderClient::dispatchDecidePolicyForNavigationAction):
Canonical link: https://commits.webkit.org/315222@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
