Difference between how Safari 14 handles iframe cookie in HTTP vs HTTPS

Question

After latest Safari update (version 14), we face strange issue with part of our Web app not loading properly.

The app consists of two parts, main domain and sub domain where each has its own dedicated server (sub domain server can call main domain server but not the other way around). On an application load, main domain server handles authentication which sets an SID cookie. Sub domain opens on user interaction from within an iframe to ensure that opening sub domain always goes throughout main domain authentication. In the sub domain iframe, there is additional security request against sub-domain-server that sets sessionToken cookie for the sub domain (using Set-Cookie response header). After this initial loading phase, sub domain makes bunch of requests against both servers which requires above cookies to be set (obviously, for proper authorization).

What is different between Safari version 14 and previous Safari versions (or any other browser) is that none of the subsequent calls to the sub domain server has ANY cookie set. Contrary (and correctly), requests that go against main domain have all expected cookies.

---

When I check the cookies storage for both domains, I can see that:

• The main domain cookie storage has all expected cookies
• The sub domain cookie storage has all cookies of the main domain (e.g. SID mentioned above) but not the cookie set by an iframe request (sessionToken)

---

So it almost looks like Safari blocks the sub domain requests from within an iframe from:

• Passing cookies to subsequent requests
• Storing cookies with Set-Cookie response header

---

To make things more complete, this problem does not occur:

• On production servers running on HTTPS (it only occurs on local dev env running on HTTP)
• When "Prevent cross-site tracking" is disabled in Safari/Preferences/Privacy

---

My understanding so far is that Safari does this intentionally, thinking that the iframe opening sub domain is an add-tracker, protecting the client. But I've read heaps of articles about Safari's ITP and understood that ITP doesn't protect sub-domains in the same way which is contradicting my use case.

---

So my questions are. Does anyone knows why:

• Is there a difference between how Safari 14 handles iframe cookies in HTTP vs HTTPS?
• Is there a proper way how to "communicate with Safari ITP" the fact that the two domains are in fact one app and not an add-tracker?
• Generally, any additional inside to understand the concept will be appreciated!

Answer 1

As per Safari 14 Version :- All third-party cookie access is blocked.

I also faced this in my company PRD server, we were setting cookie from within Iframe using sub-domain.

This happens because this case falls under first-party bounce code flow, hence Safari also protects against first-party bounce tracking.

Bounce tracking happens when instead of navigating the user directly to the target domain, the user is redirected through intermediate domains which can set cookies and build a profile of the user. Intelligent Tracking Prevention detects when domains are used solely for bounce tracking and clears all website data that might have been saved on them.

Source https://www.cookiestatus.com/

Answer 2

We've added this message to our users:

Please go to Settings > Safari > Privacy & Security and uncheck Prevent Cross-Site Tracking and Block All Cookies.