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

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.

Has anyone also experienced this or similar problems?

  • I am observing this strange behaviour, too. When I tick the box for "Disable Caches" in the Network window of the Web Inspector, Cookies are sent to the server, always. (Tested on my Mac with Safari Version 16.4 (18615.1.26.11.22))

Add a Comment

Accepted Reply

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.

We have a similar issue with Safari on iPad running version 16.4 (other versions untested) but yet be able to further debug as we have no MacBook at hand right now. But navigating will hang our page and redirect to login after refresh. So it seems to be a session cookie related regression. Deleting Safari website data resets and/or restarts the cycle. Private browsing in Safari or switching to Chrome or Edge is "helping" for now. I will try to get more details on the issue using a MacBook as soon as possible.

Replies

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.

We have a similar issue with Safari on iPad running version 16.4 (other versions untested) but yet be able to further debug as we have no MacBook at hand right now. But navigating will hang our page and redirect to login after refresh. So it seems to be a session cookie related regression. Deleting Safari website data resets and/or restarts the cycle. Private browsing in Safari or switching to Chrome or Edge is "helping" for now. I will try to get more details on the issue using a MacBook as soon as possible.

I'm having a very similar issue with an instance of Discourse I maintain. Multiple users report being intermittently & randomly. signed out after upgrading to Safari 16.4.

Occasionally, requests to my site from Safari 16.4 fail to send a user's session token cookie, despite it being present in Safari's storage. This results in my server seeing that missing cookie and "correcting" the mistake by signing the user out.

This does not happen on every request, but it's always the same cookie that gets "dropped." The main difference b/t our cases is that my cookie is not a session cookie, it has an expire time of 365 days.

I am experiencing the same issue. I log into my site using Firefox on Windows and I have cookies sent for every request, I sign into my site from Safari (16.4; os 13.3.1) and nearly all of my request are not sent with cookies.

t seems to occur when the samesite attribute of Cookie is set to "Lax" in Safari 16.4. If the samesite attribute is not set (not 'none') in my Rails Application, this problem will not occur, but it will occur if it is 'Lax'.

  • Thank you, we now use this as a workaround until the issue is fixed.

Add a Comment

hello we have the same problem. The session cookie is accidentally lost. Affected are: iphones with ios 16.4 / safari browser. when will this be fixed? will it be fixed ? or do we have to find a solution ourselves?

sebastian

We are having the same issue. ios 16.4.1 and safari browser. The odd thing is I can't find any patch-notes that explains why this would suddenly break.

Will try to change cookie samesite attribute and update if successful.

Add a Comment

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

I urge everyone to comment on https://bugs.webkit.org/show_bug.cgi?id=255524 to make Apple/WebKit devs aware of the urgency of this problem.

  • Session cookies lost on iPhone ios 16.4 and 16.4.1 Safari only. Firefox, Chrome, Edge, Opera, Brave and DuckDuckGo are all okay. Backend Flask with Seasurf 1.1.1 for CSRF mitigation. Working solution as of now is detecting iOS 16.4/16.4.1 and detecting Safari and disable CSRF checking if true and running a Referer check as a minimum protection.

Add a Comment

We’re experiencing the exact same issue with a couple of Python/Flask apps and can recreate the issue at will. It does not seem to affect “private browsing” sessions or other non-WebKit browsers. The issue seems to become less frequent with HTTPS sessions but that might be something we’re imagining since the issue does still persist.

I'm experiencing the same issue. To make it even weirder, when the inspector is open, even with 'disable cache' unchecked, it will send the cookies. I don't have an actual iOS device at hand, but this is also happening on real hardware, based on feedback from my customers.

Same issue here – only working solution with Safari 16.4 (MacBook and iPad) is to use "private window" … but this is NOT a solution!

I am developing a website. In the process we startet with Safari 16.3 and the cookie consent solution worked fine. Since I upgraded my computer to Ventura 13.3.1 and Safari 16.4 the cookie-banner, appears as a modal as expected, but nothing in the pref-field can be clicked or selected. When trying to click something the whole modal closes. Since the cookie consent solution also works based on cookies, I believe that the issues you have experienced cause the problem. Additionally on the website script based functions are corrupted or not loading. In other browsers such as Chrome (Version 113.0.5672.92) everything works fine. Also in Safari 16.3.

I am developing within webflow [https://webflow.com) The cookie-consent-solution I am using is finsweet [https://finsweet.com/cookie-consent)

Hopefully, the developers from Safari have a look into this as soon as possible!

Seems to be resolved in Ventura 13.4, iOS & iPadOS 16.5

  • Just tested: still does not working for me in Safari and Ventura 13.4

Add a Comment

We have a similar issue with Safari on iPad running version 16.4 (other versions untested) but yet be able to further debug as we have no MacBook at hand right now. But navigating will hang our page and redirect to login after refresh. So it seems to be a session cookie related regression. Deleting Safari website data resets and/or restarts the cycle. Private browsing in Safari or switching to Chrome or Edge is "helping" for now.

Our issue still holds true with Safari on iPad running version 16.5 but behavior slightly changed. Navigating continues to hang our page but there is no redirect to login after refresh. Private browsing in Safari and latest Chrome or Edge still working without problems.

Since this problem still exists in the latest Safari version (16.5.2) and we're having problems with this as well. I've added some details of our cookie problem when loading (rendered JavaScript) assets on https://bugs.webkit.org/show_bug.cgi?id=255524 It seems that any value in the SameSite attribute of the cookies causes this to happen. We could see that just 4 of the 7 cookies were kept during all requests and the other three get lost from time to time. Hoping for an official fix soon.