16

The SameSite concept for Cookies is definitely a hard one to grasp...

In preparation for Chrome 80's changes, I'm trying to measure the impact of the absence of SameSite attribute on my cookies. I have the following configuration:

  1. User initially accesses main.mysite.com
  2. main.mysite.com sets SomeCookie (Set-Cookie: SomeCookie=value; path=/; secure; httponly) and redirects to auth.mysite.com
  3. User authenticates on auth.mysite.com and is redirected back to main.mysite.com (POST request)

Because redirections between main.mysite.com and auth.mysite.com are considered as same site and because the absence of SameSite attribute is treated as SameSite=Lax by Chrome 80, this works just fine.

However, when main.mysite.com is embedded in a frame on a page hosted on another site (say othersite.com), SomeCookie is not sent back to main.mysite.com at step 3:

Illustration showing what the problem happening

Is this normal and why?

Gyum Fox
  • 3,287
  • 2
  • 41
  • 71

2 Answers2

35

The answer above is just incorrect... Let me clear up some confusions.

1. When are 2 sites the "same site" for the purposes of SameSite?

Regardless of the Domain attribute of a cookie, two sites are considered the same when their eTLD+1 (aka registrable domain) are the same. See my answer here for a more detailed explanation.

So in this case, assuming the eTLD is ".com", we would consider auth.mysite.com and main.mysite.com to be the same site because the eTLD+1 is mysite.com for both of them. On the other hand, anything.mysite.com and othersite.com are always cross-site. This is true whether it is a top-level navigation or a subresource request (like an image or a document in an iframe).

2. What does the Domain attribute mean?

If a cookie is set with Set-Cookie: cookiename=cookievalue; Domain=mysite.com, then the cookie will be sent on requests to any domain matching *.mysite.com (i.e. all subdomains).

This is a way to adjust the scope of a cookie. For example, you could use Domain=mysite.com for a global cookie that all of your domains care about, and Domain=corp.mysite.com for a cookie that all of your company's internal domains care about (but not your external-facing domains, for example).

The default (for cookies that don't explicitly set a Domain attribute) is that cookies are sent only to the domain that set the cookie. (No subdomains.)

You cannot set a Domain attribute that does not match the URL of the request.

(Also, there is no such thing as an "origin" attribute of a cookie.)

3. So what does Domain have to do with SameSite?

Nothing. They are independent cookie attributes. Domain doesn't care about the same-site/cross-site context, and SameSite doesn't care about domain/subdomain scope of the cookie.

4. When mysite.com is embedded in an iframe on othersite.com, why are default-Lax cookies not sent?

This is considered a cross-site context, because the site in the user's URL bar is othersite.com whereas the request is made to mysite.com, and these have two different eTLD+1's.

Because it's in an iframe, this is not a top-level navigation, so all cross-site requests will exclude SameSite cookies.

If it were a top-level navigation (user clicks on a link that takes them from othersite.com to mysite.com), then the request method would matter. In the vast majority of cases this would be a GET request, so a cookie in Lax mode would be sent.

Hope this helps! You can refer to the latest version of the spec for more details.

Community
  • 1
  • 1
chlily
  • 2,637
  • 1
  • 8
  • 9
  • Thanks for the detailed answer, I think the 4 points make perfect sense. However, it doesn't really answer my question. If you look at the scenario in the question, and play it inside a frame, it still doesn't make sense for me that _SomeCookie_ is not sent back to _main.mysite.com_ when _auth.mysite.com_ redirects back to _main.mysite.com_ since the two are considered as Same-Site (all of this happens inside the frame). How do you explain this? – Gyum Fox Jan 30 '20 at 09:07
  • The answer surely lies here: https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-5.2.1 (thanks @chlily for pointing to the spec), but I struggle to interpret it (it's pretty complex!) – Gyum Fox Jan 30 '20 at 09:27
  • Ah, I see. Thanks for clarifying the question. There is the notion of same-siteness for the page in the frame vs the top-level site, and the notion of same-siteness for the navigated-to site vs the navigated-from site. These are subtly different. The algorithm roughly works like this: 1. Compare the page in the frame vs the top level frame. If they are same-site, go to step 2, otherwise, they are cross-site and only SameSite=None; Secure cookies should be sent. – chlily Jan 30 '20 at 16:15
  • 2. Compare the initiator (navigated-from page) vs the requested URL (navigated-to page). If they are same-site, then all types of SameSite cookies can be sent, otherwise, it's a cross-site top-level navigation, so you have to look at the request method (GET vs POST) to determine if Lax cookies can be sent (but Strict cookies will never be sent). – chlily Jan 30 '20 at 16:19
  • Oh, I see that in your picture above, "Some Cookie" is present in the first frame (main.mysite.com) which is embedded in othersite.com. If the cookie is SameSite, this should not happen, because the frame is cross-site from the top level site. I would expect the cookie to be absent in all the mysite.com frames on othersite.com. – chlily Jan 30 '20 at 16:21
  • Please notice that "SomeCookie" is being set at step 1, and since it's missing the SameSite attribute, it's supposed to default to Lax on Chrome 80. So why would it "disappear" after the redirection at step 3? Is it because of the POST request in my scenario? – Gyum Fox Jan 30 '20 at 17:17
  • 3
    Ok. Let me know if I'm getting this right: 1. User visits othersite.com which has an iframe embedding main.mysite.com. 2. On the request to main.mysite.com the server sends a Set-Cookie containing SomeCookie and then redirects to auth.mysite.com. 3. (Still within the iframe) auth.mysite.com POSTs back to main.mysite.com, and SomeCookie is absent on this POST request. -- In this scenario, the request to main.mysite.com in step 1 is cross-site, and since it's not a top-level request, no SameSite cookies will be accepted by the browser in Step 2. So on step 3, there's not even a cookie to send. – chlily Jan 30 '20 at 17:48
  • Yes, you got it right. So the actual problem is in fact that the SetCookie made at step 1 that is ignored by the browser if I follow you. Which means that I have no other choice but to use SameSite=None cookies if I need my app to work in a frame embedded on another site :( – Gyum Fox Jan 31 '20 at 08:13
  • Hi @GyumFox , I am having the same issue with my application that is embedded as iframe in a client website (differents domains), the application and cookies works fine when I run the application directly in the browser, however, the cookies are not saved when I use the application in an iframe inside a client web site, it doesn't matter if I set sameSite='None' and secure in true. Were you able to find a solution to this? Thanks!!! – German Quinteros May 14 '20 at 05:40
  • 2
    @GermanQuinteros this must be something else. If SameSite='None' the cookie should be served. Make sure the attribute is actually applied in the cookie, sometimes your framework needs to be updated for the attribute to be set (eg we were using .Net Core 2.2, and had to update to latest 2.2.8) – Gyum Fox May 14 '20 at 07:16
  • H @GyumFox, thanks for your response. Yes, the issue was related to the library I was using to handle the cookies. The solution was to updated that library and now it works as expected. – German Quinteros May 27 '20 at 15:14
3

First of all, I'm assuming that the domain attribute of the cookie is set as auth.mysite.com and not as .mysite.com. If domain attribute of the cookie is auth.mysite.com, then auth.mysite.com and main.mysite.com are not considered as SameSite.

You need to set cookie domain property to .mysite.com so that browser can see the shared origin between the two sites and consider them as same site.

My response to your question: Yes, it is normal that SomeCookie is not sent back to main.mysite.com, when you are using iframes, for the following reasons:

  • In the absence of sameSite attribute, the value of the attribute is treated as Lax
  • SameSite=Lax is almost exactly the same as SameSite=Strict, except the fact that SameSite=Lax also allows sending cookie along 'Top-level navigations'. Top-level navigation is the type of navigation when the value inside the URL bar changes. iframe context is not interpreted as a top-level navigation.

If you want make your cookies available to iframe context, you can do two things:

  1. Set sameSite attribute value to none and at the same time, set secure attribute value to true In this way, you explicitly tell the browser your intention ( which is cross site authentication ).
  2. If you set the domain attribute of cookie to .mysite.com, then you can even work with SameSite=Strict, i.e. they will be interpreted as the same site so no extra caution will be required.
Omer Gurarslan
  • 979
  • 11
  • 15
  • You assumed right, the cookies are set for each sub-domain. And yes, SameSite=None works fine. I'm still a bit confused with the concept of "same site" though, because I understood from [this answer](https://stackoverflow.com/a/59773164/1010492) that _auth.mysite.com_ and _main.mysite.com_ would be considered as "same site" (because the TLD is _.com_). I'm guessing that it's only treated as such in the context of a 'top-level navigation' then. – Gyum Fox Jan 20 '20 at 09:10
  • Imagine that somebody has assigned simply '.com' to the Domain attribute of a cookie. If the browser wouldn't check against Public Suffix List (PSL) and accept it as is, that cookie would end up being attached to every single request ending with .com, no matter it is gmail.com or facebook.com. It is the PSL that is able to say that '.com attribute of this cookie is not enough to say that gmail.com and facebook.com are same sites'. In your example, your cookie doesn't go through PSL check because it is already long enough to exclude auth subdomain from main subdomain, and vice versa. – Omer Gurarslan Jan 20 '20 at 11:22
  • > If domain attribute of the cookie is auth.mysite.com, then auth.mysite.com and main.mysite.com are not considered as SameSite. This is actually incorrect, FYI. The Domain attribute of a cookie is separate from the SameSite attribute. The concept of whether two sites are the "same site" is based on the public suffix list. See my response [here](https://stackoverflow.com/questions/59770533/cookies-without-samesite-attribute-are-sent-on-different-sub-domains/59773164#59773164) for more details. So auth.mysite.com and main.mysite.com are *always* the same site. – chlily Jan 29 '20 at 23:48
  • Sorry I disagree. And this can easily be tested, which I did. For two URI's to be considered as same site, there are two conditions: 1- Domain attribute of cookie must match URI 2 - PSL Check must pass. – Omer Gurarslan Feb 01 '20 at 13:27
  • Quoting from MDN: "A cookie is associated with a particular domain and scheme (such as http or https), and may also be associated with subdomains if the Set-Cookie Domain attribute is set. If the cookie domain and scheme match the current page, the cookie is considered to be from the same site as the page, and is referred to as a first-party cookie." - https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#third-party_cookies – Omer Gurarslan May 16 '22 at 22:51