### Overview: In any scenarios where Safari loads tabs not as a top level navigation (eg history navigation, restore after closed/crashed window, sign in with Apple), then SameSite strict cookies are not sent over WebSocket request (only over XHR requests), which behavior is persistent, and not repaired even by tab reload (cmd+R). This breaks any cookie based authentication mechanism over WebSocket (which typically needs to use Strict sameSite cookies) which in turn can completely break applications and services using WebSockets. ### Affected version details: Experienced on Safari 14, Safari 15 - it seems to be fixed on Safari 15.1 (did not find the relevant fixed webkit report though) Even if fixed in 15.1, backport seems to be justified given the scope and implications of the issue. The issue happens on all kinds of tab loads - opening tab with Reopen Last Closed Tab (cmd+shift+T) - browser history navigation (not 100% reproducible - it seems to happen when load is not instantaneous, so when bfcache is not used) - restored tabs after application crash - after sign in with Apple if popup mode is not used - also suspected: if url is loaded with redirection (302) ### Reproduction steps: The issue is accurately described by Bradley Ayers, 2021-07-08 16:25:07 as a comment in [this issue](https://bugs.webkit.org/show_bug.cgi?id=200345) 1. Given a site (e.g. site-a.com) with page that: - sets a SameSite strict cookie (`MyStrictCookie`). - sets a SameSite lax cookie (`MyLaxCookie`). - makes an XHR request to the same domain (e.g. `/api`). - makes a WebSocket request to the same domain (e.g. `/ws`). 2. Expected behavior scenario: 1. Load the page by typing in the URL and pressing Enter. - In Web Inspector > Storage > Cookies, both `MyStrictCookie` and `MyLaxCookie` are visible. - In Network > XHR, the request sends `MyStrictCookie` and `MyLaxCookie`. - In Network > Other, the WebSocket request sends `MyStrictCookie` and `MyLaxCookie`. 3. Problematic behavior scenario: 1. Close the window. 2. Restore the window via History > "Reopen Last Closed Window". - In Web Inspector > Storage > Cookies, only `MyLaxCookie` is visible (`MyStrictCookie` is missing). - The Network > XHR, the request sends `MyStrictCookie` and `MyLaxCookie`. - The Network > WebSocket, the WebSocket request *only sends* `MyLaxCookie` (`MyStrictCookie` is missing). Other notes worth mentioning: - This behavior affects all tabs in a re-opened window. However new tabs created in that window are not affected. - If you "Duplicate Tab" from the tab's context menu, the new tab will exhibit the same behavior as the duplicated tab (i.e. it inherits some security tainting). - It seems incorrect that the XHR request sends `MyStrictCookie`, yet the cookie is not visible in Web Inspector > Storage. I'd expect consistency between the two. - Further more, the inconsistency of having `MyStrictCookie` sent for XHR but not for WebSocket seems incorrect. I'd expect it to be sent for both, or sent for neither. And playing off the previous point, given the cookie isn't visible in Web Inspector, I expected neither. - The tab can be "fixed" by focusing the location bar with the URL and pressing enter. Presumably because this causes a "top level navigation", and pages loaded via top level navigation always have access to SameSite strict cookies. - The tab behavior can be reproduced by creating a tab via `window.open('site-a.com')` from a different domain. My understanding is this simply following the SameSite spec. Is it possible that tabs in a "re-opened window" are created using a similar mechanism, and it's for that reason that they don't satisfy the SameSite strict checks, and the tabs are tainted as "not trusted".
> Experienced on Safari 14, Safari 15 - it seems to be fixed on Safari 15.1 (did not find the relevant fixed webkit report though) > Even if fixed in 15.1, backport seems to be justified given the scope and implications of the issue. We cannot go back in time to change what's already on customers' machines. Please upgrade to the latest release.
- I can't confirm 100% that the issue is completely fixed in 15.1 (given the broad number of tab open use-cases, there could be ones that are still not fixed), we could not reproduce the crash-restore and reopen last closed tab cases, but did not test others - also no time machine is needed, you can release patches to still supported major versions of your software like non-arrogant teams do - MacOS Big Sur / Safari 14 is still a supported, is it not?
It would be most appreciated if you could file a new bug for the exact case(s) that you can confirm to still be broken in 15.1. This bug report is just saying that something could be broken, and you would like us to test that. One of the folks CC'ed here may or may not be willing to test, but as far as I'm concerned, there is no reason to keep an open bug about something that hasn't been observed with the latest release yet. WebKit Bugzilla is for tracking issues that occur with latest WebKit code. We are not tracking or discussing when vendors release the fixes.