32
votes

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..

3

3 Answers

35
votes

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.
1
votes

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.

0
votes

For applications coded in Ruby (specifically, Rails, Sinatra, or anything atop Rack), the RailsSameSiteCookie gem solves this and related issues quite nicely. The code reads like a near translation of the pseudocode in the Chromium discussion without the brittle regex's.