Bug 255524 – REGRESSION (Safari 16.4): Safari sometimes doesn't send cookies for assets requests and javascript fetch requests

• Component: WebKit2
• Status: RESOLVED CONFIGURATION CHANGED

[Adrian]

On iPads after updating to iPadOS 16.4, Safari often "looses" the session in our web apps.

When the browser downloads javascript assets (from <script> tags) or when additional data is fetched by JavaScript (Fetch API), the session cookie with SameSite=Lax is not included in the request.
The Web Server re-issues a new Set-Cookie which Safari uses for future requests on the page (e.g. form submit).
This means that data stored in the cookie, like session id and shopping cart, are lost.

Expected behaviour: Since the domain of the asset/fetch requests is the same as the origin of the page, Safari should include session cookies with SameSite=Lax in those requests too.

Reproduced with:
- iPadOS on Safari 16.4 and 16.4.1
- Safari 16.4, 16.4.1, and 16.5 beta 1 on MacBook

Additional info:
- In Private Browsing this issue doesn't occur.
- Using Google Chrome, the web apps work fine too. Both on iPadOS and on MacBook.

This needs immediate attention as seems others run into that problem as well: https://developer.apple.com/forums/thread/728137

It seems there is something wrong with the SameSite cookie handling since Safari 16.4. 
There are reports that not sending a SameSite attribute at all (not "None", but no attribute at all) seems to be a workaround for now.

I am pretty sure this is a bug in WebKit.

[Radar WebKit Bug Importer]

<rdar://problem/108153254>

This issue needs attention. The workaround seems to work, but this can only be a temp-solution.

[Fab]

For now the workaround "SameSite = None" it seems to work in Safari, but it does not the best way to fix the issue.

[Jacob]

We're experiencing the same behavior. It only happens in Safari 16.4 and higher, and only intermittently.

[John]

It's important to include "Secure;" in your cookie when using Safari to help protect sensitive information. This will instruct the browser to only transmit the cookie over an encrypted connection, making it more difficult for attackers to intercept or steal your data.

Therefore, if the cookie doesn't have the "Secure;" attribute when using Safari, the browser may delete it, which could potentially impact your website or online activity. To avoid this issue, it's important to include the "Secure;" attribute in your cookies.

(In reply to John from comment #6)
> It's important to include "Secure;" in your cookie when using Safari to help
> protect sensitive information. This will instruct the browser to only
> transmit the cookie over an encrypted connection, making it more difficult
> for attackers to intercept or steal your data.
> 
> Therefore, if the cookie doesn't have the "Secure;" attribute when using
> Safari, the browser may delete it, which could potentially impact your
> website or online activity. To avoid this issue, it's important to include
> the "Secure;" attribute in your cookies.

While helpful general advice, in our case at least, the secure attribute is present and has not mitigated this behavior.

[Jerry Gregoire]

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.

[Bob Clewell]

I confirmed that the the workaround "SameSite = None" does appear to fix this issue, but it breaks functionality in Google Chrome.

[Bob Clewell]

I also confirmed add the Secure attribute does not fix this issue.

[youenn fablet]

Is there a way to reproduce, even flakily, the bug?

[Jerry Gregoire]

(In reply to youenn fablet from comment #11)
> Is there a way to reproduce, even flakily, the bug?

Yes, I have been able to using a Python/Flask app. Watch the 'session' token value and refresh any endpoint (even an empty one). Within a few refreshes, the session token will change, having been re-issued as the browser failed to deliver it's previous token to the server.

Perform the same test using a 'private' session or using any other browser and watch as the session token remains 'stable'.

[youenn fablet]

(In reply to Jerry Gregoire from comment #12)
> (In reply to youenn fablet from comment #11)
> > Is there a way to reproduce, even flakily, the bug?
> 
> Yes, I have been able to using a Python/Flask app. Watch the 'session' token
> value and refresh any endpoint (even an empty one). Within a few refreshes,
> the session token will change, having been re-issued as the browser failed
> to deliver it's previous token to the server.
> 
> Perform the same test using a 'private' session or using any other browser
> and watch as the session token remains 'stable'.

Can you provide me (privately or publicly) access to this repro app?

[Bob Clewell]

I can provide access to a Laravel (PHP) testing app with a debug bar where you can see the session token changing with each page load, if that's useful.

I can't provide repo access, though.

[Jerry Gregoire]

(In reply to youenn fablet from comment #13)
> (In reply to Jerry Gregoire from comment #12)
> > (In reply to youenn fablet from comment #11)
> > > Is there a way to reproduce, even flakily, the bug?
> > 
> > Yes, I have been able to using a Python/Flask app. Watch the 'session' token
> > value and refresh any endpoint (even an empty one). Within a few refreshes,
> > the session token will change, having been re-issued as the browser failed
> > to deliver it's previous token to the server.
> > 
> > Perform the same test using a 'private' session or using any other browser
> > and watch as the session token remains 'stable'.
> 
> Can you provide me (privately or publicly) access to this repro app?

The current (and all of the previous releases from the last 18 months) of Airflow exhibit the behavior. I can bundle something up if it helps but you should be able to fire it up like this:

1. Create a python virtual environment and activate it
2. Run `pip install apache-airflow`
3. Run `airflow webserver`
4. Open 'http://0.0.0.0:8080' in Safari
5. Watch the 'session' token in the developer console as you click repeatedly on the pinwheel logo in the upper right corner.

[arber]

Same here.

Reproduced with:
- iPhone on Safari 16.4

Additional info:
- In Private Browsing this issue doesn't occur.

[David]

We're seeing very similar behaviour on macOS Ventura 13.3.1

- JSESSIONID cookie stops being sent
- Behaviour appears to be triggered by rapid requests - clicking a link to thecurrent page rapidly twice triggers it almost every time. Waiting one second between clicks never appears to trigger it. Having a page make three 

Behaviour present in Safari 16.4

Behaviour not seen:
- In Firefox or Chrome
- If Web Inspector is opened and "Disable Caches" ticked
- In "Private Window"s

Cookies are sent over https and are of the form:
- Set-Cookie JSESSIONID=C567CBF8F644A334F94EA70416C3DEC3; Path=/; secure; HttpOnly; SameSite=strict

Its almost as if Safari has cached some content from before the cookie was issued with "no cookie" state, and then that is polluting some later requests

[stuff]

Adding to the pile. Tested and confirmed.

This needs resolution.

[[e-mail]]

Today we've spent two hours trying to find problem on our side. Please fix this, it makes some of SSR apps hard to use.

[[e-mail]]

We have also seen this bug in Chrome/Firefox (on iOS since they all use Webkit) and partially even in Private Browsing on iOS for some cookies with sameSite set to Strict.

[JanMlady]

I confirm the mentioned problem on MS IIS10 / aspx and SameSite=Lax flag since Safari 16.4. System session ASPSESSIONIDxxxxx occasionally changes.
If no flag is sent to SameSite, this problem goes away, but it is not a long-term solution to this problem.
Chrome/Firefox don't have this bug.

[ulteemo]

After several hours of troubleshooting, we finally found this bug report. We can recreate it: Random logouts from our app with Safari >= 16.4 on MacBooks or iPads. 

With Chrome and Firefox the problem does not occur. 

For now, the recommendation to our users who contact us about problems is to use these browsers as an alternative. 

If you want them to use Safari again in the future, this problem should be solved urgently!

[Vittal Aithal]

We too have seen this, with secure, http only, Lax cookies sometimes not sent with requests for images and script resources.

[Vittal Aithal]

(In reply to Vittal Aithal from comment #23)
> We too have seen this, with secure, http only, Lax cookies sometimes not
> sent with requests for images and script resources.

Seen on Safari 16.4 (18615.1.26.11.23), Ventura 13.3.1 (22E261)

[Jerry Gregoire]

Still early in the testing but I think we might be seeing a fix in the latest Safari patch included with the latest "security rapid release" macOS 12.3.1 (a), iPhone/iPad OS 16.4.1 (a).

MacOS Safari version is 16.4 (18615.1.26.110.1).

[stuff]

(In reply to Jerry Gregoire from comment #25)
> Still early in the testing but I think we might be seeing a fix in the
> latest Safari patch included with the latest "security rapid release" macOS
> 12.3.1 (a), iPhone/iPad OS 16.4.1 (a).
> 
> MacOS Safari version is 16.4 (18615.1.26.110.1).

No change observed on our end with this exact version.

[Salmane Hajouji]

I confirm this issue is still occurring even after latest update 16.4.1 (a).

Do we have a status? The workaround SameSite = None is not a viable solution security wise...

[Koshi]

Same problem happens to our osx/ios clients that are using Safari.
It happens only on the session cookies that are in "Lax" mode.

Will there be a fix soon for this?

Thank you for your time.

[Fluff]

Same problem here. I had to ask my users to stop using safari and move to chrome or edge until Apple fixes it (hopefully it won’t take several years).

[aa]

Session is also expiring in private mode.
With SameSite = None, it workings. But not a reliable solution.
In our case safari sending cookie for js and css, img assets but randomly missing in request. 
After something investigation, it seems like when adding versioning in css and js includes, safari start causing this issue. When we have removed versioning session expiration has reduce a lot for static assets.

When this fix will be available?

[Volodymyr Hryvinskyi]

We have faced the same problem, but there is an interesting observation, I can reproduce this bug only when I go to the corresponding domain (all other domains, staging, test works as wel), and i can reproduce only when I follow the links on the site, simply reloading the page does not reproduce the bug, and if you turn off the cache, the bug does not reproduce either

[Adrian]

(In reply to Volodymyr Hryvinskyi from comment #31)
> We have faced the same problem, but there is an interesting observation, I
> can reproduce this bug only when I go to the corresponding domain (all other
> domains, staging, test works as wel), and i can reproduce only when I follow
> the links on the site, simply reloading the page does not reproduce the bug,
> and if you turn off the cache, the bug does not reproduce either

I can confirm that the bug also occurs for me only when navigating the page via links. Reloading fixes the problem on the next requests.

[Volodymyr Hryvinskyi]

One more observation, this happened on our site because we had one dynamic css, every time the site was loaded it always returned the result from the server. After adding the cache-control, pragma and expires headers, the problem disappeared

[youenn fablet]

I have not been able yet to reproduce the bug on a recent macOS internal version.
A bug was fixed in that area below WebKit to address https://bugs.webkit.org/show_bug.cgi?id=230350. When downgrading before the fix, I was able to reproduce the issue.
I am not sure why this would have regressed in Safari 16.4 though.

Could somebody try the latest macOS/iOS beta, which should include the fix for https://bugs.webkit.org/show_bug.cgi?id=230350, and report the results?

[Salmane Hajouji]

(In reply to youenn fablet from comment #34)
> I have not been able yet to reproduce the bug on a recent macOS internal
> version.
> A bug was fixed in that area below WebKit to address
> https://bugs.webkit.org/show_bug.cgi?id=230350. When downgrading before the
> fix, I was able to reproduce the issue.
> I am not sure why this would have regressed in Safari 16.4 though.
> 
> Could somebody try the latest macOS/iOS beta, which should include the fix
> for https://bugs.webkit.org/show_bug.cgi?id=230350, and report the results?

Hello, I am still able to reproduce this issue on latest Safari 16.4.1 (a).

[youenn fablet]

> > Could somebody try the latest macOS/iOS beta, which should include the fix
> > for https://bugs.webkit.org/show_bug.cgi?id=230350, and report the results?
> 
> Hello, I am still able to reproduce this issue on latest Safari 16.4.1 (a).

I am thinking of the latest macOS 13.4/ iOS 16.5 betas.

[youenn fablet]

Marking as Configuration Changed based on the bug not reproducing for me after bug 230350 fix.
Please reopen if you can reproduce on the most recent iOS/macOS betas.

[Bob Clewell]

youenn, any sense of the time frame as to when the latest MacOS comes out of beta? Are we thinking a week or two or longer?

[youenn fablet]

(In reply to Bob Clewell from comment #38)
> youenn, any sense of the time frame as to when the latest MacOS comes out of
> beta? Are we thinking a week or two or longer?

We cannot provide such information.
Given RC2 was available May 11, and given what happened in the past between RC and shipping, I would guess this would not be too long.

I encourage you to have a try on the betas to validate this fixes your issue. In case there may be more than one bug, this would gain some time for additional investigations.

[Kristoffer]

I have a similar issue in a react native app, where I loose the connection in webview when app is put in the background. 
The issue started in ios 16.4.1.

I can recreate it in 16.5 RC2.

[Adrian]

I have updated to MacOS Monterey 12.6.6, which was released a few days ago.
The issue can still be reproduced using Safari 16.5 (17615.2.9.11.6).

[Salmane Hajouji]

I confirm the issue is still present on safari 16.5

[Tom]

Hi, our company encounters the same problem which is blocking a large number of users, reproduced on Safari 16.4 and Safari 16.5.
On Safari 16.3 the issue is not present.

We really have an urgent need for this to be fixed, tell us if we can help.

[Karl Dubost]

I wanted to test using the instruction in Comment #15 

mkdir bug-255524 
cd bug-255524
python3 -m venv env
source env/bin/activate
which python
# returns ~/bug-255524/env/bin/python
python3 -V
# Python 3.9.6
pip install apache-airflow
# Here you can go fetch a cafe. :p
# …
# …
airflow webserver



No Luck. 

# ImportError: urllib3 v2.0 only supports OpenSSL 1.1.1+, currently the 'ssl' module is compiled with LibreSSL 3.3.6. See: https://github.com/urllib3/urllib3/issues/2168
This affects WPT too. 
https://github.com/web-platform-tests/wpt/issues/40188


I need to find another way to test this issue. 
Or if someone can provide a minimal code configuration for reproducing the issue that would be great.

[Caleb Billing]

Our clients are still experiencing this issue, which is causing them grief, as they can be in the middle of something and then get logged out.

I'm still able to reproduce this in Safari v16.5

We have a classic ASP.NET web application.
I tried setting the 'SameSite' setting from 'Lax' (which is what our production configuration uses, for SSO) to 'None' and no attribute at all, but the issue persists.

It would be great if this could be fixed as soon as possible.

[Karl Dubost]

I tried yet another site where this was supposed to happen in a 10 minutes range and after 20 minutes it has still not happened.

macOs Ventura 13.5 + Safari Technology Preview Release 171 (Safari 16.4, WebKit 18616.1.15)

I understand the frustrations of everyone here, but without a way to reproduce it, it's quite hard to test.

[youenn fablet]

> I understand the frustrations of everyone here, but without a way to
> reproduce it, it's quite hard to test.

Agreeing with Karl here.
There might be different underlying issues related to cookies.
One has been fixed and this hopefully helped some web sites.
There might be others though and the best way to understand them is to get repro steps.

[Noel Da Costa]

I'm having this same behaviour. I have a docker env which is running so as to place the backend on https://be.mnr.localhost and the front-end on https://fe.mnr.localhost. 

This has been working for some time. In the last week or so it stopped working on Safari only. It still works fine on other browsers.

The issue seems to be that once the PHP session is successfully initiated, Safari is not passing that token in further requests, while other browsers are.

A bit of a hunt around seems to suggest this on StackOverflow:

```
It 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'.
```

And in the headers on the response from Logging in successfully I can see:
```
Set-Cookie: PHPSESSID=9b2ad6e6db9da3c4a0e84f715cf32a3a; path=/; secure; HttpOnly; SameSite=Lax
```

However, I tried setting SameSite to `None` and `Secure` to true and now I get:
```
Set-Cookie: PHPSESSID=d083183b6e3cc1b9333348a700df4d9f; path=/; secure; HttpOnly; SameSite=None
```

However, it still does not pass the session cookie in further requests from the front-end.

Safari: Version 16.5 (18615.2.9.11.4)
MacOS: Ventura 13.4 (22F66)

[youenn fablet]

@Noel, have you tried on iOs 16.5?
If it reproduces there, can you send the docker env or repro steps privately to [e-mail] and [e-mail] so that we try reproducing locally?

[Karl Dubost]

I wonder if people experiment something similar to what is described in the Bug 233128 Comment #5

[Noel Da Costa]

(In reply to youenn fablet from comment #49)
> @Noel, have you tried on iOs 16.5?
> If it reproduces there, can you send the docker env or repro steps privately
> to [e-mail] and [e-mail] so that we try reproducing locally?

@youenn I'm not sure how I would test it from iOS? The docker env is local to the MacBook Pro and its DNS routing is set up via the local `/etc/hosts` file. So I don't think that I'd be able to access that from an external device.

However, if it's of use, I can set up a GitHub repo with the docker environment and a trimmed-down version of the app that demonstrates the problem. It would be up to you to figure out how to expose that to an external device though (I'd be happy to know how if you care to share).

Please let me know if you'd like me to do that.

[Noel Da Costa]

Also it seems curious to me that you seem to be suggesting that you would only look into this issue if it affects iOS? Does desktop Safari not count?

[Karl Dubost]

N(In reply to Noel Da Costa from comment #52)
> Also it seems curious to me that you seem to be suggesting that you would
> only look into this issue if it affects iOS? Does desktop Safari not count?

Any platform is of interest. :) 
There is an issue we need to find the issue. I'm sure we will figure out once we have the right thing to be able to test it. It's just that for Youenn and I so far we have been unlucky. :)

[youenn fablet]

> However, if it's of use, I can set up a GitHub repo with the docker
> environment and a trimmed-down version of the app that demonstrates the
> problem. It would be up to you to figure out how to expose that to an
> external device though (I'd be happy to know how if you care to share).
> 
> Please let me know if you'd like me to do that.

Yes, that would be useful for us to pinpoint the underlying issue.
Please send this information to Karl and I, thanks!

[Noel Da Costa]

I managed to connect my iOS device via NAMO and installing self-signed certificates and I can confirm that the issue occurs also on iOS Safari 16.5

Next, I will do that GitHub repo as discussed.

[Adi Putra]

I encounter this issue as well on ios 16.5 and am using laravel

Maybe more clue for the Apple dev team on this bug behaviour

#1 
I load the home page and confirm the cookie is set successfully. I add the die,dump,debug [ddd($request->cookie())] in the middleware to return the cookie value and i got correct session cookie id and csrf token id when i refresh the same page. 

Note: i dont remove the ddd function when moving to observation 2
#2
Problem arise when I move to other page (i.e., login page, about page or etc). What happen is i got null value for the session cookie id and csrf token id. But what happen next maybe offer a big clue to solve this problem as when i click refresh, i get the correct session cookie id and csrf token id.

=> so this is what i believe happen to all of us. cookie is set properly but when we move to another page (let call it page 2). the browser return null value and because of this most framework will take this as new session and assign new session id. However as shown in observation #2, if i stop the framework from setting new cookie from the ddd function, on second refresh on page 2, the browser finally return correct session id

Question for others:
did you guys managed to circumvent this issue in ios 16.5 by using this method suggested by others as i try it by removing samesite attribute but issue is not resolved :(.

```
It 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'.
```

[Adi Putra]

(In reply to Adi Putra from comment #56)
> I encounter this issue as well on ios 16.5 and am using laravel
> 
> Maybe more clue for the Apple dev team on this bug behaviour
> 
> #1 
> I load the home page and confirm the cookie is set successfully. I add the
> die,dump,debug [ddd($request->cookie())] in the middleware to return the
> cookie value and i got correct session cookie id and csrf token id when i
> refresh the same page. 
> 
> Note: i dont remove the ddd function when moving to observation 2
> #2
> Problem arise when I move to other page (i.e., login page, about page or
> etc). What happen is i got null value for the session cookie id and csrf
> token id. But what happen next maybe offer a big clue to solve this problem
> as when i click refresh, i get the correct session cookie id and csrf token
> id.
> 
> => so this is what i believe happen to all of us. cookie is set properly but
> when we move to another page (let call it page 2). the browser return null
> value and because of this most framework will take this as new session and
> assign new session id. However as shown in observation #2, if i stop the
> framework from setting new cookie from the ddd function, on second refresh
> on page 2, the browser finally return correct session id
> 
> Question for others:
> did you guys managed to circumvent this issue in ios 16.5 by using this
> method suggested by others as i try it by removing samesite attribute but
> issue is not resolved :(.
> 
> ```
> It 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'.
> ```

To make it clear when i mention i got null for session id, my web framework detect there is a cookie send by safari but the value is null

[Karl Dubost]

So I manage to have airflow webserver working as recommended by Jerry Gregoire.

I clicked on the logo which increments the Expires time of the cookie after each click.


session	7850d35f-e05b-4275-a7e2-583733503dc2.YJfMlYdslG7N-2fMq9vQxIXrlR8	0.0.0.0	/	7/12/2023, 2:44:56 PM	71 B		✓	Lax
session	7850d35f-e05b-4275-a7e2-583733503dc2.YJfMlYdslG7N-2fMq9vQxIXrlR8	0.0.0.0	/	7/12/2023, 2:47:32 PM	71 B		✓	Lax
session	7850d35f-e05b-4275-a7e2-583733503dc2.YJfMlYdslG7N-2fMq9vQxIXrlR8	0.0.0.0	/	7/12/2023, 2:48:10 PM	71 B		✓	Lax
session	7850d35f-e05b-4275-a7e2-583733503dc2.YJfMlYdslG7N-2fMq9vQxIXrlR8	0.0.0.0	/	7/12/2023, 2:48:26 PM	71 B		✓	Lax
and so on…

50 clicks later 
still NO LUCK in reproducing this issue 
on Safari Technology Preview Release 171 (Safari 16.4, WebKit 19616.1.16.1) 
on Desktop with MacOS Sonoma.

As anyone reproduced the issue with STP?

[Karl Dubost]

From the comments only

Reproduced on iOS/iPadOS
* iPadOS 16.4, 16.4.1
* iOS 16.4
* iOS 16.5 RC2
* iOS 16.5

Reproduced on Desktop
* Safari 16.4, 16.4.1, 16.5 beta 1  / OS version Unknown
* Safari 16.4 / macOS Ventura 13.3.1
* Safari 16.5 (17615.2.9.11.6) / MacOS Monterey 12.6.6
* Safari 16.5 (18615.2.9.11.4) / MacOS Ventura 13.4 (22F66)


NOT reproduced 
* on private windows
* STP 171 macOS Ventura
* STP 171 macOS Sonoma
* iOS 16.3

[Tom]

Hi,

some hints that may prove useful :
- we discovered that the issue on our side was a combination of Safari 16.4+, Play Framework and Baqend service worker (a web site speed optimization tool)
- disabling Baqend solve the issue for us
- Baqend released a patched version that also fixes the issue

So it seems that a combination between Baqend service worker and a recent Safari change in 16.4+ resulted in the issue for us.

Hope it can helps 
Thomas

[Noel Da Costa]

(In reply to youenn fablet from comment #54)
> > However, if it's of use, I can set up a GitHub repo with the docker
> > environment and a trimmed-down version of the app that demonstrates the
> > problem. It would be up to you to figure out how to expose that to an
> > external device though (I'd be happy to know how if you care to share).
> > 
> > Please let me know if you'd like me to do that.
> 
> Yes, that would be useful for us to pinpoint the underlying issue.
> Please send this information to Karl and I, thanks!

Can you please confirm receipt of the Github repo invitation?

[youenn fablet]

(In reply to Noel Da Costa from comment #61)
> (In reply to youenn fablet from comment #54)
> > > However, if it's of use, I can set up a GitHub repo with the docker
> > > environment and a trimmed-down version of the app that demonstrates the
> > > problem. It would be up to you to figure out how to expose that to an
> > > external device though (I'd be happy to know how if you care to share).
> > > 
> > > Please let me know if you'd like me to do that.
> > 
> > Yes, that would be useful for us to pinpoint the underlying issue.
> > Please send this information to Karl and I, thanks!
> 
> Can you please confirm receipt of the Github repo invitation?

Yes, thanks a lot!
I have'nt been able yet to look at it.
I'll let you know.

[Rudolf Horbas]

Are there any news on this? I think we have been hit by this bug in a Laravel project, and I can't believe that something so serious doesn't cause more of an outcry. Or are there only rare circumstances that cause it?

We tried all the workarounds mentioned above, none helped.

[Tomoya YOKOTA]

I confirm this problem fixed after bellow version.

- iOS 16.5.1 (a) 
- macOS Ventura 13.4.1 (a)

I confirmed this problem fixed with iOS 16.5.1 (c), macOS Ventura 13.4.1 (c).
I test with typical serverside render web application using Cookie Session.
the attribute of Cookie is Expires/Max-Age: Session, HttpOnly: true, Secure: true, SameSite: Lax.

Are there someone who stil experiancing the messy problem with latest macOS/iOS?

[Noel Da Costa]

(In reply to Tomoya YOKOTA from comment #64)
> I confirm this problem fixed after bellow version.
> 
> - iOS 16.5.1 (a) 
> - macOS Ventura 13.4.1 (a)
> 
> I confirmed this problem fixed with iOS 16.5.1 (c), macOS Ventura 13.4.1 (c).
> I test with typical serverside render web application using Cookie Session.
> the attribute of Cookie is Expires/Max-Age: Session, HttpOnly: true, Secure:
> true, SameSite: Lax.
> 
> Are there someone who stil experiancing the messy problem with latest
> macOS/iOS?

@Tomoya The problem is in the Safari browser, not in the OS.
It is definitely not fixed.

[Vittal Aithal]

@Noel Da Costa 
The release note (https://support.apple.com/en-us/HT213825) for macOS Ventura 13.4.1 (c) includes this:

"and fixes an issue that prevents some websites from displaying properly"

For me (at least with some quick tests), this seems to have resolved the issue in Safari for me.

[Karl Dubost]

macOS Ventura 13.4.1 (c) is unrelated to this issue. 
It was related to UA parsing.

[Arjan]

Created attachment 467085 [details]
An image of the cookies that should all be present

This bug is not resolved as the problem still exists in Safari Version 16.5.2 (18615.2.9.11.10). Actually; I just stumbled on this bug when investigating an issue with assets sometimes not loading causing errors in our web application. Some assets called by a <script src=..> tag are rendered bij ASP.NET MVC Controllers. Their output (JavaScript) is used in the web application. These assets can't be cached, because it might contain download tokens or server side settings which may change over time.

What I discovered was that the assets were not loading correctly because sometimes after a few clicks / navigating in the web application, the assets were loaded with just 4 of the 7 cookies that should be sent. 3 cookies are lost, including the authenticated session. I've attached an image with the cookies (and their configuration) that should be present with all calls to the server. However the ones with a red square before them (sorry for my drawing skills) are the ones that get lost from time to time (all having some value in SameSite).

The times that not all cookies are sent to the server are just random. It's possible that it works like 7-8 times with all the cookies sent and the 9th time the 3 cookies are lost. Then the user is logged out in our controller (causing the errors when loading the assets and resetting the session). All within a timespan of seconds to minutes. This problem only exists in Safari and it keeps happening after multiple clicks/navigating from page to page.

Bug still occurs on 
Safari Version 16.6 (18615.3.12.11.2)
and
Safari TP Release 174 (Safari 17.0, WebKit 18616.1.22.1)

on macOS 13.5 (22G74)

It logouts me randomly from gmail.com and other not saves closed cookie banners etc

[ed]

I might be running into this issue as well. It seems that while part of my requests are being handles as expected, there are several css requests that randomly lose the cookie.

[ed]

(In reply to ed from comment #70)
> I might be running into this issue as well. It seems that while part of my
> requests are being handles as expected, there are several css requests that
> randomly lose the cookie.

Tested a bit more thoroughly, cookies are indeed not being sent with css requests. They are present in chrome and firefox.
System is latest developer beta macos Sodoma, Safari Version 17.0 (19616.1.27.211.1)

[Karl Dubost]

ed, what is you configuration
* OS version
* Device version
* Browser
* Server used
* Software etc.

Is there a public site which is usable for the problem you are experiencing.

From my side one thing I need to add - after DISABLING developer tools in Safari, the problem looks like resolved. 
For about 10 days I didn't get problems with cookies.

[ed]

(In reply to Karl Dubost from comment #72)
> ed, what is you configuration
> * OS version
> * Device version
> * Browser
> * Server used
> * Software etc.
> 
> Is there a public site which is usable for the problem you are experiencing.

I will try to replicate and ship that to render.com and also share the code on github. Will come back later today with some links.

[ed]

(In reply to ed from comment #74)
> (In reply to Karl Dubost from comment #72)
> > ed, what is you configuration
> > * OS version
> > * Device version
> > * Browser
> > * Server used
> > * Software etc.
> > 
> > Is there a public site which is usable for the problem you are experiencing.
> 
> I will try to replicate and ship that to render.com and also share the code
> on github. Will come back later today with some links.

I built a separate example reusing some code to try to reproduce, which I have been able to partially achieve. here's the working link https://safari-cookies-test.onrender.com -- clicking the link will set the cookie then redirect back to /.
Here's the repository with the code https://github.com/edimoldovan/safari-cookies-test

What I have found so far is that when Safari is connecting directly to the Go app, that is when the issue occurs. In the above url it works fine because I believe render uses a reverse proxy of some sort between the app and Safari.

The cases where it doesn't work:
- localhost, where there is no proxy running or 
- my actual production, where I accidentally forgot to set up Nginx or Caddy but the Go app still works as it runs and serves content directly on :443

And here are the answers for the system related questions:

* OS version: Sonoma 14.0 (23A344)
* Device version: Apple M1 Pro
* Browser: Safari Version 17.0 (19616.1.27.211.1)
* Server used: Go
* Software etc. everything is implemented in Go's Standard Library mostly

On the same system above everything works as expected in Firefox Developer Edition 118.0b9 (64-bit) and Chrome Version 116.0.5845.187 (Official Build) (arm64).

What happens in Safari feels like cookies are not being set at all on localhost.

[Malik]

Cookie related issue still occurs in Safari Version 16.5.1.
Changing "Same Site" attribute from "Lax" to "None" resolved the issue, but this is not a reliable solution due to security concerns.

[Malik]

Cookie related issue still occurs in Safari Version 16.5.1.
Changing "Same Site" attribute from "Lax" to "None" resolved the issue, but this is not a reliable solution due to security concerns.

I've been affected by this bug since last march. It has driven me crazy as I thought at first that it was due to the security policy that my company IT had installed on our macs. (I still wonder to this day, could it be an external process wiping some session/cookie files for security purpose?)

I've no clue as to why and how to fix this bug, but I'll give you details that might be of use to reproduce/understand it.

I managed to circumvent the issue by using safari technology preview which did not log me out every few minutes. With the release of MacOS Sonoma I tried going back to safari and it worked for a few glorious week, but today, suddenly, the issue is back

I've developper tools activated, I toggle the disable cache often in the network tab.

My company makes me use Okta for sso on the websites I noticed the issue

I close and reopen safari frequently.

I lock my session whenever I leave my laptop.

I've disabled/uninstalled all the extensions I had.

I've disabled `prevent cross site tracking` in my settings to circumvent a login issue I had running our webapp on localhost

I encounter this issue on google.com and gitlab.com and okta.com where it'll ask me to connect multiple times a day.


I understand perfectly how hard it can be to track a bug you cannot reproduce and seem to not affect everyone, I can simply hope that one of the random facts I've listed here might spark the beginning of the understanding of what is going on.


I believe a key point is that I've never had the issue in private mode or in safari technology preview. Only in plain safari, which lead me to believe that something is messing with whatever is publicly accessible in safari.



Anyway, Thanks for all the hard work you put in this amazing browser and best of luck tracking this bug

[Caleb Billing]

I don't think this has been mentioned yet, we have identified that it is iframes that are causing this issue in our application.

We were able to fix it in a couple of places in our application that were using iframes that didn't necessarily need to and removing them made those pages not have this issue anymore.
However there is one place left that uses iframes which is fundamental to its functionality and it is still causing sporadic issues for users using Safari.

[Chris Chambers]

Is the status of this bug correct? It's currently RESOLVED CONFIGURATION CHANGED, but it seems that it's still a problem. Should it be re-opened?

[Karl Dubost]

Yes I was hesitating to re-open or open a new bug for it. 
I let Youenn decides, which of these two.

[Karl Dubost]

OK I opened Bug 265634

[Karl Dubost]

There might be a fix for Bug 265634
https://github.com/WebKit/WebKit/pull/21801

Thanks everyone for your participation.

[Noel Da Costa]

This is still a problem with Safari Version 17.2.1 (19617.1.17.11.12)
Why has this bug been marked as resolved? It has not been resolved.

Please advise.

[Noel Da Costa]

This is still a problem with Safari Version 17.2.1 (19617.1.17.11.12)
Why has this bug been marked as resolved? It has not been resolved.

Please advise.

[Noel Da Costa]

The problem for me that persists (regardless of whether developer tools is switched on or off) is that localhost domains, such as `fe.dev.localhost` and `be.dev.localhost` should allow the browser to save the cookie. 

In my case I have a VueJS front-end app connecting to a PHP api on the backend. On all other browsers besides Safari this works fine.

I have Caddy server managing this with the following Caddyfile:
```
fe.dev.localhost {
    reverse_proxy host.docker.internal:8080
}
be.dev.localhost {
    root * /var/www/html/be/webroot
    encode gzip
    php_fastcgi php:9000 
    file_server
}
```
But on Safari the browser refuses to store the cookie that is delivered by the backend after a successful login when the server-side session is started.

There must be some way provided by Safari to allow devs to code on an environment without having them map a FQDN - i.e. on localhost.

This occurs regardless of Samesite settings set by the server – I've tried them all.

[Noel Da Costa]

I also just noticed that when inspecting the login request response on Chrome, the received  Cookie has the Domain value set to `be.dev.localhost`. However, on Safari the cookie that is showing has no Domain value. It is being sent by the server but the Domain value for the cookie in the Safari inspector shows as blank.

[Noel Da Costa]

Also noticed that on the same request, Chrome shows matching Request and Response cookies, while Safari shows only a Response cookie.

[Karl Dubost]

Noel Da Costa, did you try in STP 189?