Set cookie inside iFrame domain not seen

Question

I'm trying unsuccessfully to set a cookie in an iframe cross-domain. I've found elsewhere (https://stackoverflow.com/questions/2117248/setting-cookie-in-iframe-different-domain, https://stackoverflow.com/questions/4701922/how-does-facebook-set-cross-domain-cookies-for-iframes-on-canvas-pages) that it should be possible with some caveats.

My scenario is the following: I have a page served from https://a.com/sample which contains an iFrame served from https://b.com/sample. The b.com/sample page set a cookie for b.com domain (samesite=none, secure, httponly).

If I load the original b.com page https://b.com/sample in the browser window I correctly see the cookie set and it is available for other b.com pages (https://b.com/some-other-page); If I load the https://a.com/sample page I see the cookie set inside the page, but if I switch to other b.com domain pages the cookie is not available.

I suppose this is due to cross-domain security checks (I tried on Safari and Firefox), is there any way to make this work? I see the same behavior if I switch to localStorage

Answer 1

There are two reliable ways without any tricks.

1. Send data from one domain to another via an explicit request. In your case, b.com can send a request to a.com, and a.com can do whatever it needs, e.g. set these data to cookies for a.com.

2. Send needed data via Window.postMessage(). Using this method, the IFrame of b.com can send any data to the window of a.com. The code in the a.com windows can do whatever needed, e.g. set these data to cookies.

Answer 2

This used to work, but is now blocked in some browsers, especially with high-privacy settings in place, due to state partitioning. State partitioning causes cross-origin (or at least cross-site) embedded content to receive a distinct set of storage (cookies, local storage, etc.) for each top-level site.

Browsers that feature state partitioning will generally also support the storage access API, which can be used to request that the user allow the embedded page to use cookies (but not other storage, at present). There are also currently some heuristics that are used in certain cases (such as when redirecting from a page) to temporarily allow such access.

At present, state partitioning is not universally adopted. In Firefox, for example, it's active if the user has their tracking protection settings set to "Strict", or if the browser is in private (incognito) mode. Safari has long had its own version of state partitioning, which works a bit differently. However, the web in general is moving toward state partitioning (or blocking cookies in third-party content altogether) by default.

As such, you should avoid embedding pages that are expected to be used in an authenticated context. If you can't, you should expect that users will have the bad experience of needing to log in within the embedded context (which savvy users won't do, because for all they know the "embedded context" could be a phishing page, and savvy sites won't permit their login pages to be framed anyhow). Either use redirection, new windows/tabs, or (where relevant) server-side fetches rather than expecting cross-site embedding of authenticated content to work. If you must have it, though, consider the storage access API.