4

I have Web application and API application.

These applications are hosted on different domains.

Eg.

WebApp: app.product.com

API: api.product.com

Cookies are set in Set-Cookie header in response to API call:

api.product.com/SetCookie -> response header Set-Cookie: cookie_name=cookie_value; path=/; secure; HttpOnly; SameSite=None

Than I'm making request to API again and I need this cookie to be attached to request headers.

Everything works fine on most of popular browsers, but on Safari (version 13.1+) this cookie is not set (it's not visible in dev tools even).

Cookie is visible in response response with cookie

But its not stored in browser cookies enter image description here

I was trying to set domain attribute of cookie to 'product.com' but it didn't resolve problem.

Is there any way to set cross domain cookies in that case? Maybe by changing set cookie attributes.

Or hosting all applications from same domain will solve the problem?

smyq
  • 41
  • 1
  • 2

3 Answers3

2

If possible, hosting from the same domain will solve this problem, because the iframe cookie will no longer be 'third-party' and thus the restrictions will be lifted.

In Safari, the third-party frame will have to request access to the Storage API before the cookie will be accessible.

There have been numerous changes in all of the browsers regarding cookies and iframe.

The basics of what is changing is there is now a 'SameSite' cookie policy, where Only cookies set as SameSite=None; Secure will be available in third-party contexts, provided they are being accessed from secure connections.

Firefox is using a partitioned approach to the storage, and so the frame will behave as normal unless you then open your application as a new window then the cookie store may or may not follow depending on how the new window was created.

Cookie Status is an excellent resource to track how third party cookies work in the different browsers and what you should change to make it work.

pfranza
  • 3,292
  • 2
  • 21
  • 34
  • 3
    Good advice, but the OP didn't say anything about iframes. Rather, they mentioned contacting the API. In other words, they're performing an XHR. – rinogo Oct 20 '21 at 20:28
  • P.S. Thanks for the excellent link to Cookie Status! – rinogo Oct 20 '21 at 20:30
0

From version 13.1 Safari is completely blocking third party cookies https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/

Aleksandar
  • 79
  • 3
  • 10
0

Did you press the reload button at the right top corner of the Storage tab? I use Safari 14.1.1 and build a similar environment to do the same test. But got a different result, even if the Safari never visited the api.example.net as first-party. I am still able to write cookies on it. What I do:

  1. Visit app.example.net.
  2. Open devtool and go to the Network panel
  3. Execute fetch('https://api.example.net/x.php', {method: 'POST', credentials: 'include'});.
  4. The x.php will returns set-cookie in Header Set-Cookie: test=test; expires=Mon, 06-Sep-2021 09:42:18 GMT; Max-Age=5184000; secure; HttpOnly; SameSite=None
  5. Execute again, I can see this cookie is sent with the second request.
  6. I also use an iframe on another page to embed api.example.net. So it will not be first-party. And I can see the storage data of that domain. Just like the screenshot provided by @smyq. And after press the reload button. The cookie appears in the devtool.

But I didn't expect this behavior. I think it violates the Safari's default cookie policy. And Safari is blocking all 3rd party cookies now.

PS. If I do this on a very different domain name, not just a different subdomain. The cookie will be blocked by ITP's tracking prevention. I enabled ITP debug mode to get the info.

OOO
  • 324
  • 2
  • 5