6

I need some help understanding a case which I can not find described in material I have found describing the new SameSite restrictions for Chrome. Currently, I have a case where I have a site hosted which makes cross-site requests to an API. The API responds with CORS headers. The details are:

Site: https://a.a.com
API: https://b.a.com

--API response headers

Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://a.a.com

--cookie previously set with

Set-Cookie: value=somevalue; Path=/; Expires=<some time/date>; HttpOnly

I don't expect the CORS headers to impact anything (based on everything I have seen it never mentions the SameSite changes) but I am putting them here anyways. Given this scenario and when I set the flags at:

chrome://flags/#same-site-by-default-cookies
chrome://flags/#cookies-without-same-site-must-be-secure

I would expect the browser to block the sending of the cookie value. This being because I would expect the cookie to be treated as if it had SameSite=Lax and that these are cross-site requests. This is not what actually happens and the cookie is sent successfully. When testing this, I also tried waiting 3 minutes between any requests and a POST request to avoid the "Lax+POST" mitigation as we set the cookie (with updated expiration) on every response. Based on what I am reading about the changes, I don't understand why the sending of this cookie is not blocked by the browser and why these requests succeed.

To make things more confusing, we have some cases during development with the following scenario:

Site: http://localhost
API: https://a.b.com

--API response headers

Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: http://localhost

--cookie previously set with

Set-Cookie: value=somevalue; Path=/; Expires=<some time/date>; HttpOnly

Unlike the first scenario described, these requests actually block the cookie from being sent as expected (only when new chrome flags are enabled). The warning message the browser gives is related to SameSite and Secure flags as I would expect.

Can someone help me understand why the first scenario is working yet the second is not? My concern is that it working is actually a bug and it shouldn't. If this is the case, it may be possible that in the future it might, without warning, go from "working" to "failing".

Details of the Chrome changes/flags I found are here:

Goblinlord
  • 3,290
  • 1
  • 20
  • 24

1 Answers1

6

as mentioned here https://web.dev/samesite-cookies-explained/:

If the user is on www.web.dev and requests an image from static.web.dev then that is a same-site request.

Same as your first case:

Site: https://a.a.com
API: https://b.a.com

So the browser considers your first request as a same-site request and cookies won't be removed, but the second one is a cross-site request and cookies without samesite attribute will be removed.

melbx
  • 319
  • 1
  • 3
  • 17
  • @Goblinlord it's saying that that's a cross-site because github.io is a service and the site is the suffix github.io + the part of the domain just before it. read the paragraph before this. – melbx Mar 23 '20 at 00:28
  • 2
    Actually, I did. This is extremely confusing to me. It states: "The public suffix list defines this, so it's not just top-level domains like .com but also includes services like github.io. That enables your-project.github.io and my-project.github.io to count as separate sites." I am failing to see why "a.a.com" and "b.a.com" are same but the example they give my-project.github.io -> your-project.github.io that's a cross-site request. It is basically the same difference in format. – Goblinlord Mar 23 '20 at 00:34
  • Also, it says both "com" and "io" are in this public suffix list so I don't understand the distinction between these 2 examples (they seem the same to me but they are saying one is same and one is cross). – Goblinlord Mar 23 '20 at 00:36
  • hmmm... github.io is literally in this list. So if it is IN the list it would be "cross"? In "mine.github.io", "github.io" is literally in this public list. In "static.web.dev" only "dev" is in this list. So the list "excludes" things from being "same"??? – Goblinlord Mar 23 '20 at 00:40
  • 1
    Actually, I think I got it. Site, would refer to "a.com" with site being public suffix plus the next part? In "mine.github.io", the entire thing is the "site" because "github.io" is listed in the public suffix list. – Goblinlord Mar 23 '20 at 00:45