Home > Back-end >  Why is a SameSite=Strict cookie for http://127.0.0.1:12345/ not being sent in Android browsers?
Why is a SameSite=Strict cookie for http://127.0.0.1:12345/ not being sent in Android browsers?

Time:02-03

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?

CodePudding user response:

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:

  1. Use http://localhost or http://localhost.localdomain instead of http://127.0.0.1
  2. Set the Secure attribute on the cookie
  3. Set Location on the 302 response to an absolute URL (http://127.0.0.1:12345/) instead of just the path
  4. Clearing browser cache and cookies
  5. Set Cache-Control: private, no-store, must-revalidate on the 302 response

With 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:

  1. 1221316 - SameSite context type should consider redirect chain - chromium
  2. 150066 - Set-cookie ignored for HTTP response with status 302 - chromium (closed wontfix)
  3. 696204 - Cookies are ignored on 302 redirects - chromium (closed wontfix)
    • This comment talks about setting the 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.
  4. Change cookie domain handling for IP address host
  • Related