Safari 16.4 seems to lose session cookies on asset requests or javascript fetches

[profinoob]

On iPads after updating to iPadOS 16.4, Safari often "looses" the session cookie provided by PlayFramework: When the browser requests assets (js scripts) or when additional data is fetched by JavaScript, the session cookie is not included in the request.

These secondary requests will redirect through our IAM because no session cookie is present. The IAM redirects back to the original domain with a payload so that the login session can be resumed. A new Set-Cookie header is sent in the response with the new session cookie.

This causes the framework to issue a new CSRF token (that is part of the session cookie) which is different from the old one that was already rendered into a hidden form input. The browser stores this new token and includes it when it POSTs the form. The token in the body of the request is now different from the one in the cookies, causing the CSRF check to fail.

We have tried different devices (Android, Windows, MacBook, and iPads) on different versions. The problem only occurs with Safari on iPad/MacBook running version 16.4, 16.4.1, or 16.5 beta. The problem cannot be reproduced using Chrome on iPad. Furthermore, the problem does not occur with private browsing in Safari.

Some things we ruled out:

• Same behaviour on devices managed by MDM and on open devices.
• PlayFramework version is now updated to the latest 2.8 version.
• Using a separate cookie for the CSRF token (instead of the play session cookie) does not make a difference either.
• Modifying the Cache-Control header to cache responses more aggressively or not at all does not help.
• Clearing browsing data on the devices does not fix the issue

Has anyone also experienced this or similar problems?

[mkurz]

Are the js files hosted on the exact same domain like the page is served? Or from a (different) sub domain?
How do you fetch the js files? Using XMLHttpRequest, javascript fetch, etc.?

[profinoob]

The requests where the cookies seem to be lost are either js assets, included via <script> tags or javascript fetch(...) requests.

[mkurz]

According to https://developer.apple.com/forums/thread/728137 this might be related when the SameSite attribute is to lax which is the default for Play's session cookie (and all other cookes set by Play).
I would try to set

play.http.session.sameSite = null

in your config and see if that works (don't forget to clear the cookies in Safari before you try again).
If that works, could you also try again by setting the value to None? Would be interesting if that works. According to the thread it also does not work with None, in which case I am pretty sure this is a bug in Safari.

Also, do you serve the requests over https? I mean is the secure attribute of the session cookie set? Seems, at least in chrome, the browser does not accept SameSite=None if the the secure attribute is not set.

[mkurz]

I think it would be a good idea to also open an issue in the webkit bug tracker.

[profinoob]

With play.http.session.sameSite = null the application also works as expected in Safari.
Setting it to None is not possible via the configuration. This feature is not yet included in any version.

All http requests are redirected to https by a proxy. The proxy is responsible for the SSL termination using the customer facing certificate.
The play service hosts on https using the generated self-signed certificate.

The cookies are not set to Secure.

[hertg]

This bug from 2019 seems very familiar
https://bugs.webkit.org/show_bug.cgi?id=196375

[mkurz]

Given that it works in other browsers and in Safari's private mode, I am pretty sure this is a bug in webkit/Safari and there is not much we can do from Play's side to fix that. For now you can set the sameSite config to null and wait for a Apple to fix Safari.

[mkurz]

Given that it works in other browsers and in Safari's private mode, I am pretty sure this is a bug in webkit/Safari and there is not much we can do from Play's side to fix that. For now you can set the sameSite config to null and wait for a Apple to fix Safari.

And of course if you do that make sure you (still) have Play’s CSRF protection activated:

• https://www.playframework.com/documentation/2.8.x/ScalaCsrf
• https://www.playframework.com/documentation/2.8.x/JavaCsrf

Setting it to None is not possible via the configuration. This feature is not yet included in any version.

That's not true, you problably looked at #11757 where I only added a comment to the reference config three days ago because it wasn't mentioning the option to set it to None. You can set it to None in Play 2.8 and we even backported that to 2.6.x: #9612 However according to that comment the workaround only works when the SameSite Cookie is not set at all and the bug still occurs with None. Therefore I would just set Play's config to null, which also has the nice side effect that Chrome (and maybe other browsers?) will still set the attribute to lax, because Chrome switches cookies without SameSite attribute to Lax by default since a while. Also in case you would use None, you have to make sure that the Secure attribute is set as well: https://web.dev/samesite-cookies-explained/

[profinoob]

I have opened an issue for webkit: https://bugs.webkit.org/show_bug.cgi?id=255524