Bug 272325 – REGRESSION (iOS 17.x): Session cookies being reset randomly in a Home Screen web app

• Component: Website Storage
• Status: NEW

[Ricardo Cristino]

Hello,

My company provides a low-code platform used by a large number of companies around the world. We have applications running on all the major browsers, PWAs, native Android, and native iOS. Recently, a few customers who upgraded iOS (from what we could determine, to iOS 17.2 - 17.4.1) have reportted that the session cookies were getting lost in PWAs and native apps. We also have similar reports on Edge 123.0.2420.56 and lower versions. Considering that this misbehavior can be replicated in the simplest applications, we are concerned that more customers will become affected.

The authentication flow of all applications shares the same flow:
1. A user accesses an application for the first time;
2. The server replies with two set-cookie headers which define two persistent cookies with default values (let's call them cookies A and B);
3. These two cookies are always sent together with the "Cookie" header in the subsequent requests;
4. The user logs in and the server replies with three Set-Cookie headers: cookies A and B are changed to different unique values with session expiration; and a third session cookie C is also created/modified;
5. Here, the user is authenticated, those 3 cookies are passed in the "Cookie" header to authenticate any request to the server. 

The observed issue is that after the login, having already three session cookies, we suddenly detect that the "Cookie" header contains values different than the ones set after the login. Cookies A and B no longer have a session value but, instead, were reset to the persistent default value obtained in step 2. Cookie C still has the same session value. An important detail is that document.cookie has the expected cookie values. This causes the authentication to fail and the users lose their session randomly.

Note that the application javascript is not interfering with the cookies (some are HTTPOnly which forbids javascript from accessing them). We placed traces everywhere on the backend and proved that the server never replied with a set-header cookie from the instant the login happened to the instant the cookies changed. So, only some underlying iOS mechanism could be switching valid session cookies by others which were set several requests back. We made some investigation and came across multiple threads reporting behaviors and findings extremely similar to ours:
https://forums.developer.apple.com/forums/thread/728137
https://bugs.webkit.org/show_bug.cgi?id=255524 (supposedly resolved but with comments from developers suggesting the behavior is still happening in supposedly fixed versions)

Being no experts on iOS, we can't tell if those issues have the same underlying cause. But given that this issue is happening even in the latest iOS 17.4.1 version, we can say that it has not been resolved yet.

We can replicate the issue on a PWA installed on iPad 17.4.1 with the default browser Safari:
1. After close/reopen the PWA, we confirm that session cookies A and B are automatically reset to the persistent default ones. Cookie C still has the same session value as before closing the app.
2. Then we login, get new session values for all three cookies;
3. We navigate through the app, making some requests to the server.
4. Sometimes we lose the session, others don't.
5. When we don't lose the session, we start over from 1. until it happens.

If we change to the default browser (e.g. Chrome), we can't replicate the issue anymore on the PWA. It is interesting to note that we no longer lose the session simply by closing and reopening the app. If we revert the default browser to Safari, the issue does not replicate and the session is not lost once we close and reopen the app. We have to clear the History and Cookies for the behaviors to reappear again.

We played with Same Site, switching it from None to Lax, unchecked Prevent Cross-Site Tracking, generated a native iOS app instead of using the PWA, etc. All these tests did not mitigate the issue.

For testing purposes, we modified our backend not to send a set-cookie C header in any response. Without cookie C on the app, this issue is much harder or impossible to replicate. Curiously, this is the only cookie that is just set as session and never as persistent.

In another test, we set cookies A, B, and C as persistent instead of session. We could not replicate the issue based on our tests. 

Keep in mind that we can't be sure if other tests made in different devices and circumstances would produce the same results. So, don't take these results for granted.

Having said this, we can't change our entire authentication mechanism. It is also difficult to ask all iOS users to install Chrome. So, we kindly request your cooperation in fixing this issue.

Regards,

[Alexey Proskuryakov]

Thank you for the report! Would it be possible to share more detailed steps to reproduce, with a URL to test with?

[Ricardo Cristino]

Created attachment 470815 [details]
Video of the issue

We have a PWA installed on iPad 17.4.1. This device uses Safari as the default browser. We install the app as a PWA (access the app through the browser and add it to the home screen). Then, we open it, click login, and choose an item from the list. If the issue does not happen, close the app and start over. At some point, a 403 error happens. Usually one needs more than 5 attempts.

[Ricardo Cristino]

I'm working on providing a public endpoint for you to test it, we don't have one at the moment.

[Ricardo Cristino]

Hi team, 

I've attached a link to an application where the behavior is replicated (in the URL field of the bug). Access that URL on the browser in iPad 17.4.1 and add it to the Home Screen to run as a PWA. Then repeat these steps:
1. Open the PWA and the previous session is lost;
2. Click "Login with Username" button to get new session cookies;
3. You'll get redirected to a screen called Market with a list. You can click one of the items from the list and wait 1 or 2 seconds to see if the 403 error shows up in an alert message. No need to wait much more than this.
4. If the error does not pop up, just close the app and repeat the whole process again until a 403 error happens. Notice that closing the PWA causes the previous session cookies to be lost (we don't know if this is expected).

Right after installing the app for the first time, the session cookies were not getting lost when closing and reopening the app. I kept opening and closing it multiple times (less than 10 times). At some point, every time I closed the app, the session cookies were getting lost upon reopening. This is also a misbehavior that is very inconsistent from my perspective. Why does the PWA lose the session when you close and reopen it? Why is this behavior not consistent the first times you close and reopen it?

Regarding cookies A, B, and C that I mentioned earlier, their corresponding names in the app are "nr1Users", "nr2Users", and "Users".

We are now receiving reports from more major companies about this same issue. Please consider this bug report an opportunity to prevent a large-scale issue. We are interested in cooperating to resolve this.

Thank you

[Radar WebKit Bug Importer]

<rdar://problem/126138221>

[Alexey Proskuryakov]

Thank you! I cannot reproduce this on an iPhone with iOS 17.5 beta. Not getting any 403 alerts, and only saw the "Login with Username" screen once, after installing the app. I did force quit it a number of times.

However, I did get to the "Login with Username" screen again, after rebooting the device. Which suggests that some state may be kept in memory even over force-quitting? And perhaps that process gets terminated in your case for some reason.

I do not know much about how WebApp works architecturally, but I'll look for someone who would have insight.

[Ricardo Cristino]

(In reply to Alexey Proskuryakov from comment #6)
> Thank you! I cannot reproduce this on an iPhone with iOS 17.5 beta. Not
> getting any 403 alerts, and only saw the "Login with Username" screen once,
> after installing the app. I did force quit it a number of times.
> 
> However, I did get to the "Login with Username" screen again, after
> rebooting the device. Which suggests that some state may be kept in memory
> even over force-quitting? And perhaps that process gets terminated in your
> case for some reason.
> 
> I do not know much about how WebApp works architecturally, but I'll look for
> someone who would have insight.

Hi Alexey,

Thank you for following up.

I could see your attempts on my back-office audits. Indeed, the error did not happen. It is usually difficult even for me to replicate it for the first time but, once it starts happening, it's very easy to get the 403.

I would like to add that the people who have been able to replicate the error in this particular app were located in the European Union. Just in case there is any difference in the underlying technology used by our devices.

And also, there is a logout link inside the Settings tab. You can force the logout from your app when you are not losing the session. You can click it a few times to see if you can initiate the reported behavior. After a few attempts, you can close the app without logging out and the session is lost anyways.


Regards,

[Ricardo Cristino]

And it's much easier to replicate on iPad 17.4.1. On iPhone, the error is much more difficult to replicate. Our users reported that they struggled a lot more to get that error on iPhone.

[Alexey Proskuryakov]

I was unable to reproduce the 403 error on an iPad either, but there is clearly something quite wrong.

- I had an iPad Pro, so bigger memory size may have masked the issue.
- About half of the time, I needed to click the login button after relaunching, which was not the case on iPhone before.
- Once, tapping the client card wouldn't do anything, I had to force-quit the webapp without getting to the last step. 

The needing to login aspect certainly looks wrong, it shouldn't be random whether we still have the cookies after relaunching.

[John Wilander]

Just to make sure, by session cookies, do you mean cookies without any of the two Set-Cookie attributes Max-Age and Expires?

[Ricardo Cristino]

(In reply to John Wilander from comment #10)
> Just to make sure, by session cookies, do you mean cookies without any of
> the two Set-Cookie attributes Max-Age and Expires?

correct, they default to session when missing those values on the set-cookie header.

[Ricardo Cristino]

Hello team,

We have large companies under a lot of pressure due to the instability of their apps. As mentioned, this is affecting native apps as well (cordova-based). We just shared the PWA app as an example because it was the easiest way we could find to replicate the misbehavior.

As some of these companies operate in highly regulated industries, they can be fined. 

Could you share with us the current status of the investigation?

Regards,

[Àlex Fiestas]

I believe that we have been suffering the same bug, although with a WKWebview.

Some metadata that hopefully will help you locate the error.

We started to get negative reviews around 2 months ago. Some users can reliable reproduce this every 24h or 48h.

We added a log statement on every request using a WKNavigationDelegate that will check if the login cookie was present and also print getAllCookies.

What we have been able to observe is that there is a ~30% chance that the first requests will not have any cookies, or at least they won't be available in the NavigationDelegate. After the third request or so cookies are sent.

I took a look at the webkit source code and it seems that the cookie initialization is async. Perhaps this is simply a race condition?

[Ricardo Cristino]

Hello team, I would like to add a few details here. As mentioned before, the authentication flow of our applications is as follows:

1. A user accesses an application for the first time;
2. The server replies with two set-cookie headers which define two persistent cookies (Max-Age of 1 year) with default values (let's call them cookies A and B);
3. These two cookies are always sent together with the "Cookie" header in the subsequent requests;
4. The user logs in and the server replies with three Set-Cookie headers: cookies A and B are changed to different unique values with session expiration (no Max-age); and a third session cookie C (no Max-age) is also created/modified;
5. Here, the user is authenticated, those 3 cookies are passed in the "Cookie" header to authenticate any request to the server. 

During our tests we also observed that the error could not be replicated if we change step 2:
2. The server replies with two set-cookie headers which define two session cookies (no max-age defined) with default values (let's call them cookies A and B).

We hope these details can help your engineering team address this issue.

[Brady Eidson]

I believe I was able to reproduce this awhile ago in iOS 17.5 and 17.5.1
I tried in the iOS 18 beta 2 (released yesterday) and was unable to reproduce.

Unfortunately because it's *not* 100% reproducible, I'm not yet confident in the results, but if some other change has come in here and fixed this, then there's nothing left to explore.

Have you had a chance to look in the iOS 18 beta(s) yet?

[Ricardo Cristino]

Hi,

If you used the link I provided to replicate the issue, there is no evidence in the logs that any error occurred this week.

Regarding testing on iOS 18, I can have a look, but considering that even in the affected iOS versions the issue is not consistently replicated, I don't have a high degree of confidence that just because it does not happen on your iOS 18 tests it means that the issue was fixed. 

From the meetings with Apple regarding this topic, I was informed that the engineering team had been able to replicate and understand the issue but the root cause was still unknown. After all this time, considering the impact of this issue on our company and strategic customers, I was expecting to receive a more delicate message. For instance, what were the conclusions of your analysis, the possible root cause, and what was done in the most recent versions that could potentially mitigate this issue.

I'm going to provide some feedback on the iOS 18 version, but please note that we might need some time to gather this information from a sample of our user base.

Regards,

[Ricardo Cristino]

Hi,

I tried to check if there was evidence of the issue occurring on iOS 18 Beta, but there are still very few users with the beta version. It's a neglectable percentage of the total user base, so I can't still extract reliable numbers to say if the issue is occurring. But I'll keep an eye on it.

We are receiving more and more complaints from users affected by this issue, mainly on iOS 17.4.1. 

We would really like to hear some feedback on the status of the investigation. 

Regards,

[Miguel Freitas]

Hello team,

We continue to receive support requests from our customers regarding this issue.

Could you please provide a status update on what has been done so far and what are your planned next steps?

Almost two months have passed since Ricardo's request for a status update and no answer was provided.

Please let us know if we can help you in any way.

Regards,

Miguel Freitas

[Miguel Freitas]

Hello team,

We continue to receive support requests from our customers regarding this issue.

Could you please provide a status update on what has been done so far and what are your planned next steps?

Almost two months have passed since Ricardo's request for a status update and no answer was provided.

Please let us know if we can help you in any way.

Regards,

Miguel Freitas

[Jordan Carlton]

Hello,

I’m a developer for an important UK government website with approximately 1 million monthly users, and it appears as though this issue is preventing some from being able to successfully complete our online form.

We use encrypted session cookies to store user answers as they progress through the service. There are 15-20 questions in the application and we update the cookie after each answer. We have observed that Apple devices on iOS 17 upwards will sometimes present an outdated session cookie on POST requests. From our application logs, it looks like this is affecting roughly 0.35% of iPhone users, so about 1,500 visitors per month. We have not seen any patterns to when this happens.

Our cookies are updated on a POST request for each page and given an updated timestamp property, which has allowed us to track down specific instances of this occurring. Here is a typical example:

1) User makes a GET request to /page-x
	a) User presents a session cookie with timestamp 15:27:38.846Z
2) User makes a POST request to /page-x
	a) Cookie timestamp is updated to 15:27:55.735Z
	b) User is redirected to /page-y
3) User makes a GET request to /page-y
	a) Cookie with timestamp 15:27:55.735Z is correctly presented
4) User makes a POST request to /page-y
	a) Cookie with timestamp 15:27:38.846Z is incorrectly presented
	b) This is the cookie from step 1 - the application JavaScript is not interfering with the cookies, which are marked “HTTPOnly”. The only possible explanation is a bug causing the browser to serve an outdated cookie.
We have not seen any similar issues on any other browsers; this does appear to be an iOS WebKit bug.

Interestingly, I’ve seen some users restart the service with a new cookie after hitting this session bug, only for their cookie to be reset again at exactly the same point in the journey. Other users have been able to successfully complete the service on repeat runs. We haven’t been able to reproduce the issue internally.

We don’t think this bug has been resolved as of the latest iOS release – we have observed it happening for users on iOS 18.1.

Please could you let us know if you have a timescale to fix this bug? It is preventing a significant volume of users from being able to use our important government site. Fixing this bug is fairly urgent from the perspective of our service. 

We would be happy to assist with further info if it would aid in fixing this; please reach out on the email in my profile.

Many thanks,
Jordan Carlton

[Jordan Carlton]

We are still seeing this bug for around 70 users per day. Is there any update on a fix?

We've been able to add a workaround in the mean time, which hinges on our observation that this bug only seems to present on POST requests.
On each page of our service, which generally corresponds to a question the user must answer, we now pass the cookie from the HTTP GET request into the POST request as a hidden form input, and check in the application code on POST that the cookie from the form and the cookie from the HTTP headers match. If not, we compare timestamps and use the more recent cookie passed in as form input, rather than the stale one provided in the HTTP headers.

We're only taking the above steps for iPhone users, determined via the user-agent header; no other browsers appear to have problems storing and retrieving cookies.

We've observed from application logs that this has fixed the cookie issue for affected iPhone users, who are no longer seeing the errors we know are indicative of the bug and are now able successfully use our services again.
We still eagerly await a fix for this bug, and hope to receive an update soon.