Bug 219650 – Cookies set with SameSite=Lax are not sent during redirects in Safari

• Component: Page Loading
• Status: RESOLVED CONFIGURATION CHANGED

[Rajaram Gaunker]

We do Oauth redirect in a popup opened using window.open. Outh redirect from accounts.google.com redirects to our domain and we do 2 more redirects but these redirect does not send `SameSite: Lax` cookies from our domain.

This works on chrome on Firefox.

As per my understanding SameSite: Lax should be working incase of redirects.

Is there any reason why Chrome/FF and Safari deviate in this behavior.

[Alexey Proskuryakov]

Could you please provide a complete test case? Similar issues have been fixed before, so I don't think that this is a general problem.

[Radar WebKit Bug Importer]

<rdar://problem/72407777>

[Chris A]

I can confirm this issue. Lax session cookie not returned by Safari. Setting to None ok. Confirmed on macOS and iOS/iPadOS latest stable releases as of today.

Found this issue while implementing a Stripe Checkout page. Stripe Checkout is a Stripe hosted checkout page where you click a link on your site and it takes you to Stripe in same tab and not in iframe. You provide a link back to your site for the "cancel_url".

Clicking the cancel url takes you back to your site but the session id is empty and user is redirected to reauthenticate. If you then open the cancel_url via the addressbar instead of signing in again, Safari finds the cookie and reauthenticates you. 

If you click the cancel_url on the Stripe Checkout page in a new tab Safari sends the session cookie. If you click the Safari back button it works as well.

[Chris A]

(In reply to Chris A from comment #3)

I should also note that I duplicated this error outside of Stripe by creating a simple html page on another server with a link back to my localhost development environment and also a link back to a staging server secured with https. To be clear, the issue presents itself both in...

http(localhost app) -> https(live web server with link back) -> http(localhost app)

https(live server app) -> https(live web server with link back) -> http(live server app)

SSL certificates for https are valid as well.

[Viktor Holmberg]

I can also confirm this bug. In our case, we've got a paypal integration that does some payment stuff on paypals site, and then redirects back to our site using 

window.location.replace = "https://our-site-url".

When the user then returns to our site, their cookies are not sent along, and they get a 404 because their payment can't be found. (We only allow you to see payments if you have the right session id, stored in the lax cookie).

This payment flow works without issue in firefox and chrome. 

I do not have a minimal test case but I should be able to provide one on request.

[Wilson Page [:wilsonpage]]

I can also confirm this issue.

Since add `SameSite=Lax` to my auth cookies I'm seeing cookies not being sent by Safari to the Stripe Checkout success page.

1. mysite.com/checkout (cookie sent)
2. checkout.stripe.com
3. mysite.com/checkout-success (no cookie sent)

In my log I've seen this with following user-agents:

- Mozilla/5.0 (iPhone; CPU iPhone OS 14_4_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.3 Mobile/15E148

- Mozilla/5.0 (iPhone; CPU OS 14_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) FxiOS/33.0  Mobile/15E148 Safari/605.1.15

- Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1 Safari/605.1.15

- Mozilla/5.0 (iPhone; CPU iPhone OS 14_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/87.0.4280.163 Mobile/15E148 Safari/604.1

But I've yet been unable to reproduce this locally :-/ I think my current workaround will be to user-agent sniff and not use the `SameSite` functionality at all for Safari based browsers.

[Wilson Page [:wilsonpage]]

I just managed to reproduce this on latest desktop Safari (14.0.3 (16610.4.3.1.7)).

Facts:

- The cookie was missing on the first page request when Stripe navigates from checkout.stripe.com => mysite.com causing broken checkout flow.
- The issue is resolved when removing 'SameSite=Lax' flag from set-cookie header.
- I wasn't able to repro on localhost, perhaps due to not using 'Secure' flag?
- Devtools were closed during my repro (unsure if this is related)

I'm now user-agent sniffing and not including 'SameSite=Lax' for all Safari based browsers.

---

In order to produce a reduced test case we'd need to use two domains. It would likely look like this:

1. Load site1.com/ and set-cookie with `Secure` and `SameSite=Lax`
2. Click link and load site2.com/ page
3. Click link to site1.com/callback page
4. Print inbound `cookie` header
5. Observe missing cookie

[Steffen Weber]

We use SameSite=Lax for login cookies on our website (https://www.computerbase.de/) as a defense in depth against CSRF. Users have started to report that they appear logged-out when clicking on a ComputerBase link the Google search results using Safari. Google uses a redirect there (at least when using Safari) so this is probably exactly the issue we are facing. SameSite cookies are therefore essentially broken in Safari for our use-case.

I don't know that else we could do other than to use user-agent sniffing to disable SameSite cookies for IE6… err I mean Safari users. (╯°□°）╯︵ ┻━┻

[Steffen Weber]

It could be that only pages served by the fetch event handler of our service worker are affected. Google SERP links to our forum pages (which are not handled by the service worker) are working fine.

[John Wilander]

Looking at this. It may be a network layer bug rather than a WebKit bug.

[John Wilander]

I have now tried to reproduce this and I'm not able to. These are the two cases I've tested:

# Redirect Case
1. Go to siteA.example
2. Set one SameSite=Lax cookie and one SameSite=Strict cookie
3. Navigate to siteB.com which makes an HTTP 302 redirect back to siteA.com
4. Check the cookies in the HTTP request for siteA.com and find the SameSite=Lax cookie but not the SameSite=Strict cookie

# Manual Navigation Case
1. Go to siteA.example
2. Set one SameSite=Lax cookie and one SameSite=Strict cookie
3. Navigate and land on siteB.com
4. Navigate and land on siteA.com
5. Check the cookies in the HTTP request for siteA.com and find the SameSite=Lax cookie but not the SameSite=Strict cookie

Is there something you are doing that I am not? I tested in Safari Technology Preview 122 on macOS Big Sur and I tested with both secure and non-secure cookie settings.

[John Wilander]

We may have to drill into HTTP methods and exactly how navigations and redirects happen if you are still reproducing this. I do see some references to popups and window.open() which is a special case for navigations. Let me know if that is something that seems necessary to reproduce.

[Rajaram Gaunker]

Thanks John for looking into this.

In my bug SameSite=lax cookie was set during redirect dance.

1. navigate https://siteA.com/x (in our case it was https://accounts.google.com/o/oauth2/auth/oauthchooseaccount)
2. (1) use javascript to redirects to https://siteB.com/a.html
3. returns 302 https://siteB.com/b.html, sets sameSite=Lax,HttpOnly,secure cookie
4. request to https://siteB.com/b.html doesn't send the cookie in previous response.

[Steffen Weber]

First of all, thank you for looking into this issue! This is not my typical experience with Safari bugs and therefore appreciated a lot.

I don't have a Mac and therefore cannot run the Safari Technology Preview. I do have access to an iPad with iPadOS 14.5.1 but using the Safari Developer Tools on iOS/iPadOS seems to require a Mac again... So this is how I can reproduce the issue using Safari "14.0.3 (16610.4.3.1.7)" on Big Sur using BrowserStack:

1. Fetch a SameSite=Lax demo cookie by visiting https://www.computerbase.de/api/samesite-demo-cookie (*)
2. Search Google for "computerbase"
3. Open the "Network" tab of the developer tools
4. Click on the search result that leads to our homepage (may not the first one depending on your location)
5. In the "Network" tab, find the "document" request and have a look at the cookies sent by Safari. For now, the "samesite-demo-cookie" is there.
6. Now reload our homepage. (Maybe this causes our Service Worker to fully initialize / activate?)
7. Repeat steps 2-4. Now the cookie doesn't get sent anymore.

(*) I've created this script because other cookies set by ComputerBase don't use SameSite=Lax in Safari anymore because of this bug.

[John Wilander]

Thanks for the further details. I'll try to reproduce again.

[John Wilander]

(In reply to Rajaram Gaunker from comment #13)
> Thanks John for looking into this.
> 
> In my bug SameSite=lax cookie was set during redirect dance.
> 
> 1. navigate https://siteA.com/x (in our case it was
> https://accounts.google.com/o/oauth2/auth/oauthchooseaccount)
> 2. (1) use javascript to redirects to https://siteB.com/a.html

I tried both an automatic set of document.location.href on page load and a manual button click that triggered a set of document.location.href.

> 3. returns 302 https://siteB.com/b.html, sets sameSite=Lax,HttpOnly,secure
> cookie
> 4. request to https://siteB.com/b.html doesn't send the cookie in previous
> response.

For me, in Safari Technology Preview 122 on macOS Big Sur, this flow does not reproduce the bug.

Which version of Safari are you running in? On which platform? Thanks!

[John Wilander]

(In reply to Steffen Weber from comment #14)
> First of all, thank you for looking into this issue! This is not my typical
> experience with Safari bugs and therefore appreciated a lot.
> 
> I don't have a Mac and therefore cannot run the Safari Technology Preview. I
> do have access to an iPad with iPadOS 14.5.1 but using the Safari Developer
> Tools on iOS/iPadOS seems to require a Mac again... So this is how I can
> reproduce the issue using Safari "14.0.3 (16610.4.3.1.7)" on Big Sur using
> BrowserStack:
> 
> 1. Fetch a SameSite=Lax demo cookie by visiting
> https://www.computerbase.de/api/samesite-demo-cookie (*)
> 2. Search Google for "computerbase"
> 3. Open the "Network" tab of the developer tools
> 4. Click on the search result that leads to our homepage (may not the first
> one depending on your location)
> 5. In the "Network" tab, find the "document" request and have a look at the
> cookies sent by Safari. For now, the "samesite-demo-cookie" is there.
> 6. Now reload our homepage. (Maybe this causes our Service Worker to fully
> initialize / activate?)
> 7. Repeat steps 2-4. Now the cookie doesn't get sent anymore.
> 
> (*) I've created this script because other cookies set by ComputerBase don't
> use SameSite=Lax in Safari anymore because of this bug.

I'm not an expert on ServiceWorkers. Before I pull a coworker in on that part, are the cases where you don't see the SameSite=lax cookie in the page load request 1) only for requests that go to your ServiceWorker, 2) possibly only for requests that go to your ServiceWorker but you don't know for sure, or 3) both for requests that go to your ServiceWorker and ones that hit the network directly? Thanks!

[Steffen Weber]

Our service worker has a scope of "/", i.e. it is used for _all_ requests, so there is no request that is out of scope for our service worker.

But (and maybe you meant that): The fetch event handler of our service worker doesn't handle all requests, for some requests it just returns "null" to let the browser handle the request (as if the service worker didn't exist). For example, the fetch event handler of our service worker returns "null" for all forum URLs (all URLs starting with "https://www.computerbase.de/forum/"). It turns out that those URLs have no problem with same-site cookies: When I click on the search results entry for our forum (should be displayed when searching for "computerbase", if not then search for "computerbase forum") then the same-site demo cookie is always there as expected. If I then go back to the SERP and click on our homepage link again, the cookie is missing. Go back to the SERP and click on our forum link again, the cookie is there again. And so on...

So we have the following: 1) Same-site cookie is sent to our homepage on first try, bot not anymore after one or two reloads (probably after the service-worker has been initialized and our fetch event handler is used). 2) Same-site cookie is always sent to our forum pages who are ignored by the fetch event handler.

I think the combination of these two observations indicates that there is an issue with same-site cookies for requests sent by the fetch event handler.

[John Wilander]

(In reply to Steffen Weber from comment #18)
> Our service worker has a scope of "/", i.e. it is used for _all_ requests,
> so there is no request that is out of scope for our service worker.
> 
> But (and maybe you meant that): The fetch event handler of our service
> worker doesn't handle all requests, for some requests it just returns "null"
> to let the browser handle the request (as if the service worker didn't
> exist). For example, the fetch event handler of our service worker returns
> "null" for all forum URLs (all URLs starting with
> "https://www.computerbase.de/forum/"). It turns out that those URLs have no
> problem with same-site cookies: When I click on the search results entry for
> our forum (should be displayed when searching for "computerbase", if not
> then search for "computerbase forum") then the same-site demo cookie is
> always there as expected. If I then go back to the SERP and click on our
> homepage link again, the cookie is missing. Go back to the SERP and click on
> our forum link again, the cookie is there again. And so on...
> 
> So we have the following: 1) Same-site cookie is sent to our homepage on
> first try, bot not anymore after one or two reloads (probably after the
> service-worker has been initialized and our fetch event handler is used). 2)
> Same-site cookie is always sent to our forum pages who are ignored by the
> fetch event handler.
> 
> I think the combination of these two observations indicates that there is an
> issue with same-site cookies for requests sent by the fetch event handler.

This to me sounds like a separate bug. Would you agree? This one is "Cookies set with SameSite=Lax are not sent during redirects in Safari."

I suggest you file a new bug named "Same-site lax cookies not sent by fetch event handler after page reload," describe it like you did above, relate the new bug to this bug, and CC me and my coworker Youenn Fablet on it. Thanks!

[Steffen Weber]

You are right, this is the new bug report: https://bugs.webkit.org/show_bug.cgi?id=226386

[John Wilander]

Rajaram, could you check with a recent Safari Technology Preview, please? I was not able to reproduce as can be seen in https://bugs.webkit.org/show_bug.cgi?id=219650#c16.

Steffen, thanks for filing the new bug. I'm relating it to this one and have pinged my coworker Youenn on it.

[Rajaram Gaunker]

@john: Sure, will do. My test setup is broken. Will get to it by weekend.

[John Wilander]

Final call, Rajaram, before I resolve this bug as not reproducing on trunk. Thanks!

[Bret]

This is definitely still happening in Safari 15.1 as well as the latest STP: Release 135 (Safari 15.4, WebKit 17613.1.7.3)

When a cookie is set with sameSite: lax, and you redirect away to an auth provider in an oauth flow and it redirects you back to your site, no cookies are available in safari, when they are in chrome and firefox. 

Do you need assistance coming up with an example website that demonstrates this?

I ran into this when trying to implement https://next-auth.js.org.

[Bret]

Looks like its a little more complex than I though. Safari is still swallowing cookies when samesite = lax (when it shouldn't), but only when we have a service worker installed.  Still characterizing the issue to figure out if its something wrong with our service worker (which works fine with other browsers) or some other kind of safari specific issue.