Bug 210946
| Summary: | hasStorageAccess returns false is same-site cross-origin iframes | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Steven Englehardt <senglehardt> |
| Component: | New Bugs | Assignee: | John Wilander <wilander> |
| Status: | NEW | ||
| Severity: | Normal | CC: | wilander |
| Priority: | P2 | ||
| Version: | Other | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Steven Englehardt
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
Thanks for filing, Steve! I made a review comment about this in the ongoing Storage Access API spec work.