SameSite cookies, frames, sub domains and redirections

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.

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.