Safari LocalStorage not shared between IFrames hosted on same domain

user_7247920 0
Viewed 4005

We are working on two web applications that are hosted on two different subdomains of the same domain:

  • https://subDomainA.domain.com
  • https://subDomainB.domain.com

Both web applications are showing an iFrame hosted on a third subdomain:

  • https://subDomainC.domain.com

We are using postMessage to communicate between top window and IFrame window.

Within the iFrame shown on subDomainA, we are setting an AuthToken:

localStorage.setItem("AuthToken", "JWTAuthToken")

When we navigate to subDomainB and try to run the following code within the iFrame:

localStorage.getItem("AuthToken")

The result is null.

  • This only happens in the Safari browser.
    • All other browsers share the LocalStorage within these IFrames
  • We are on the same domain, i.e. the same "eTLD+1" (domain.com)
  • Doing the exact same thing with cookies works!. Just not with LocalStorage
  • Opening subDomainC directly in the browser and setting the data persists them for the IFrames as well.

Is this a indended behaviour of Safari or do we have an issue with our implementation?

local-storage safari iframe javascript
3 Answers

This is the expected behavior in Safari. Safari's Intelligent Tracking Prevention (ITP) partitions browser storage based on the top frame. Here's how WebKit's documentation explains it:

Partitioning is a technology to allow third-parties to use storage and stateful web features, but have those isolated per first-party website. Let’s say adtech.example is a third-party under both news.example and blog.example and that adtech.example uses LocalStorage. With partitioned LocalStorage, adtech.example will get unique storage instances under news.example and blog.example which removes the possibility to do cross-site tracking through LocalStorage.

References:

https://webkit.org/tracking-prevention/#partitioned-third-party-localstorage

Iframe localStorage on Safari and Safari mobile

In slightly plainer English, https://github.com/zendesk/cross-storage says :

Notes on Safari 7+ (OSX, iOS)

All cross-domain local storage access is disabled by default with Safari 7+. This is a result of the "Block cookies and other website data" privacy setting being set to "From third parties and advertisers". Any cross-storage client code will not crash, however, it will only have access to a sandboxed, isolated local storage instance. As such, none of the data previously set by other origins will be accessible. If an option, one could fall back to using root cookies for those user agents, or requesting the data from a server-side store.

This may be of use: https://webkit.org/blog/8124/introducing-storage-access-api/

user_52433090

According to the same-origin policy, different subdomains are considered cross-origin.

You should use postMessage for cross-origin communication.

user_129452810

It seems that the recent updates to the Safari browser (Prevent cross-site tracking) blocks any cookies from being generated when the Matomo domain doesn't match the website it's being loaded from.

This breaks the use of iFrames for Matomo that require cookies to be set (For example the logme feature)

There doesn't seem to be any way to fix this with headers (Eg using CSP or CORS configurations).

current workarounds exist that I've found:

  1. Disable the "Prevent cross-site tracking" setting in the Privacy settings
  2. Redirect the visitor to the page outside of an iFrame to set the cookie - after this the iFrame can load as long as the CORS configuration is correct and the browser isn't completely blocking the iFrame from loading.

I'm not sure how many users are using iFrames that would require cookies to be set, but they would be impacted if any of their users use Safari.

user_170868700
Related