Safari not sending cookie even after setting SameSite=None; Secure

Question

Our application uses cookies to remember user login. Every auth API call we make, the browser attaches server-set HTTPonly cookie with the API request and gets authenticated. This behaviour seems to be broken in safari after Mojave release.

I read about the cross-site cookie security implemented by safari and our server team added SameSite=None;Secure while setting the cookie. Even after that, it still doesn't work.

Set-Cookie: my_cookie=XXXXX; path=/; secure; HttpOnly; SameSite=None

Please advise or provide links from people who actually found a solution..

Solution 1

Versions of Safari on MacOS 10.14 and all browsers on iOS 12 are affected by this bug which means that SameSite=None is erroneously treated as SameSite=Strict, e.g. the most restrictive setting.

I've published some guidance in SameSite cookie recipes on either:

• Using two sets of cookies to account for browsers that support SameSite=None; Secure and those that don't.
• Sniffing the user agent for incompatible browsers and not serving SameSite=None for those requests.

Solution 2

This is an issue also in Safari 14. Safari is not sending third-party cookies by default anymore. This is because they introduced Privacy Preference: "Prevent cross-site tracking" which is turned on by default. So if you set your cookies with SameSite=None; Secure they still don't be set and sent cross-domain.

Solution 3

The issue is not about Safari sending or not the cookie, it's about Safari not storing the cookie. This is related to a specific combination of cookie config, it's working with this setup for localhost

Set-Cookie: your=cookie; Domain=localhost; Path=/; Expires=Mon, 26 Dec 2022 12:53:02 GMT; HttpOnly; SameSite=Lax

and this setup for prod

set-cookie: your=cookie; Domain=something.com; Path=/; Expires=Thu, 22 Dec 2022 04:17:44 GMT; HttpOnly; Secure; SameSite=Lax

you need to include Domain on both and Secure for your prod (ssl) env. You can use different values for SameSite but Lax is what works for me

Solution 4

I tried disabling "Prevent cross-site tracking" option in MAC OS (i.e., Settings > Safari > Privacy & Security > Prevent Cross-Site Tracking - disabled) and iframe started to work. I know this is not a fix but might be a quick workaround for a short time.

View more solutions

Comments

[Admin]

Hello Rowan, Thanks for the reply and apologies for the late response. I've asked my server-side team to try out the guidance from the web.dev link above. Maybe this is a completely inappropriate question to ask, anyway here goes. Since millions of users are affected by the change, any news if there is a plan in future from the apple team to resolve it?

[rowan_m]

I can't speak for the Apple / Safari team. I think the original bug is the best place for those discussions.

[IncredibleHat]

Good lord. Just spent the last three days with a customer who was having the darnedest time returning from paypal because cookies appeared to be missing (thus no session to continue buying).... and they were on an older Safari/webkit than current.... this issue described the problem exactly.

[igorsantos07]

According to the bug report, it seems they don't plan to backport the fix because it's sort of intentional. Safari's cookie policy is different, and thus, somehow, it's allowed to behave differently than the other browsers when it receives an unknown property. Just Apple being Apple, in the end.

[Frank Q.]

What safari version has the fix then ?

[Admin]

Please add further details to expand on your answer, such as working code or documentation citations.

[Georgi Dimitrov Dimitrov]

Wow man, I am really grateful I have come across your answer. You literally saved my life. I had been struggling for the past 2 days at work on this problem and I tried many things and could not seem to find any solution until I found your answer. I appreciate people like you! :)