We have a cross-platform app that runs a web server on 127.0.0.1, on a randomised port. The server code is the same on each platform.
An example URL: http://127.0.0.1:12345/
To authenticate requests, a session cookie is set on the initial response. That cookie has HttpOnly
and SameSite=Strict
set, to improve security.
Just this week we have found that in current versions of most Android browsers (Chrome 109.0.5414.85, Chrome Beta 110.0.5481.40, Firefox 109.1.1, Edge 109.0.1518.53), authentication is failing. With the Chrome dev tools, I can see that the cookie is not being sent in requests, although it is in the cookie store. If I manually change SameSite=Strict
to SameSite=Lax
(undesirable) using the dev tools, the cookie is sent, and everything starts working normally.
Opera (73.1.3844.69816) is not affected, and neither was Chrome before it was upgraded on the test tablet (possibly a pre-100 version). I have not been able to find any relevant recent changes in Chrome.
The puzzling part is, this problem doesn't exist on Windows or iOS (Mac not tested yet); there is no problem using the app on Windows under the 109.x versions of Chrome, Firefox, and Edge.
If it was a browser policy issue (despite this being a same-origin request), I would expect it to carry across platforms. If it was a browser bug, I wouldn't expect both Chrome and Firefox to be affected.
What am I missing?
We still don't know the reason for the problem, but a work-around is to change the initial response (the one that sets the session cookie) from a 302 redirect to a 200 response with a <meta http-equiv="refresh">
tag (as described in this answer).
Other things that we tried, without success:
Secure
attribute on the cookieLocation
on the 302 response to an absolute URL (http://127.0.0.1:12345/) instead of just the pathCache-Control: private, no-store, must-revalidate
on the 302 responseWith the redirect, the Chrome dev tools showed this message about the session cookie:
This cookie was blocked because it had the "SameSite=Strict" attribute and the request was made from a different site. This includes top-level navigation requests initiated by other sites.
Some bugs and commits that may be relevant:
--enable-experimental-cookie-features
command-line argument. Doing that on Windows made no difference to behaviour.Cache-Control
header on the redirect to prevent the browser caching the response. The rest of the discussion seems to be about an unreliably-reproducible problem.