WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
210946
hasStorageAccess returns false is same-site cross-origin iframes
https://bugs.webkit.org/show_bug.cgi?id=210946
Summary
hasStorageAccess returns false is same-site cross-origin iframes
Steven Englehardt
Reported
2020-04-23 17:41:55 PDT
Tested in
r260403
. hasStorageAccess() returns false in same-site cross-origin iframes. As an example, see the bottom of the middle iframe (test.senglehardt.com) in this test page:
https://senglehardt.com/test/dfpi/storage_access_api.html
. Also note that the same cookies are accessible when test.senglehardt.com is visited directly as a first party (e.g.,
https://senglehardt.com/test/dfpi/set_storage_stable.html
). Based on
Bug 202281
it sounds like this might be intentional, but it doesn't match my expectation. Same-site iframes (even those that are cross-origin) *have* access to their first-party cookies. Since requestStorageAccess only covers cookies in WebKit, there is no reason for these iframes to call requestStorageAccess()--it's effectively a no-op. Perhaps this was chosen because other storage APIs are partitioned between same-site cross-origin frames? FWIW we're experimenting with storage isolation in Firefox [0]. We don't isolate any same-site storage (so same-site, cross-origin iframes have access to all of their first-party storage--localStorage, indexedDB, etc). We also currently return false in same-site, cross-origin iframes but view this as a bug. See:
https://bugzilla.mozilla.org/show_bug.cgi?id=1622212
. [0]
https://bugzilla.mozilla.org/show_bug.cgi?id=1549587
Attachments
Add attachment
proposed patch, testcase, etc.
John Wilander
Comment 1
2020-04-23 18:02:15 PDT
Thanks for filing, Steve! I made a review comment about this in the ongoing Storage Access API spec work.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug