Same-site cookies

Table of Contents

Back to index

If you would like to see a demonstration of the main point of this post then please see https://github.com/mwpb/web-attacks and navigate to the csrf folder. In that repository there are instructions about how to set up a some docker containers to demonstrate the various attacks.

1 Definitions

Origin: Two URLs have the same origin if and only if they have the same scheme, host-name and port.

Site: The host's most specific public suffix AND the next specifier. This is sometimes written as eTLD+1 which stands for Effective Top-Level Domain plus one.

The definition of public suffix is made in the public-suffix list and may change. For more information (including the definition of 'schemeful same-site') please web.dev/same-site-same-origin.

The 'SameSite' cookie indeed concerns itself with sites and not origins.

2 Examples

https://www.example.org has .org as the most specific public suffix. Therefore the site is example.org.

https://mwpb.github.io has github.io as the most specific public suffix. Therefore mwpb.github.io is the site.

3 Same-site and cross-site requests

4 Consequences

If a subdomain on the same site is compromised then cookies set by one will be sent to the other.

So strictly speaking cross-site request forgery (CSRF) is ruled out by setting SameSite=strict. However a similar attack may still be perpetrated by URLs on the same site but which are not under your control. This makes CSRF a confusing name because the same style of attack may still occur on the same site.

So the SameSite=strict cookies will still be sent. For the purposes of defence in depth in case a subdomain gets compromised: it is a good idea to use another strategy in addition to SameSite cookies. If you only support clients using modern browsers then you can check the Origin header on the server-side. Otherwise using CSRF tokens might be appropriate.