SameSite cookies, frames, sub domains and redirections

Gyum Fox picture Gyum Fox · Jan 17, 2020 · Viewed 7.1k times · Source

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?

Answer

chlily picture chlily · Jan 30, 2020

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.