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 asLax
SameSite=Lax
is almost exactly the same asSameSite=Strict
, except the fact thatSameSite=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:
- Set
sameSite
attribute value tonone
and at the same time, setsecure
attribute value totrue
In this way, you explicitly tell the browser your intention ( which is cross site authentication ). - If you set the
domain
attribute of cookie to.mysite.com
, then you can even work withSameSite=Strict
, i.e. they will be interpreted as the same site so no extra caution will be required.