Same-Site Cookie

Rachita Bansal
4 min readOct 4, 2020
Photo by The Creative Exchange on Unsplash

What is a cookie?

Diagramatic representation of cookie.

A cookie is a key-value pair that’s sent by the server in the headers when sending a response back to the client. The client, browser this case, then saves it and sends it back with every successive request to the server.

Cookies have been a standard way of sending data to the server for a long time only until after it was replaced in favor of other more superior ways in which modern browsers would store and send data for e.g. local/session storage, local forage, index-db, etc.

One of the biggest downsides of using a cookie for storing data is that it’s sent with every request sent to the server even when the server doesn’t expect so. This would mean additional network traffic and thus increasing latency.

The server sets a cookie in the browser using http header.
The server sets a cookie in the browser using an HTTP header.

First-party / third-party cookie

There are various different sources that a cookie can be set in a website e.g. when a cookie sent with a same-site request to the server it’s called a first-party cookie, whereas, when a cookie is sent with a cross-site request it’s a third-party cookie (same-site here means the top-level domain such as .io but it includes the subdomain, so for e.g. my-user.github.io is a different site than your-user.github.io ).

Cookies may come from different domain and depending on if the domain is same or different (cross-site) they are termed as f
Cookies may come from different domains and depending on if the request is same-site or cross-site
they are termed first-party or third-party cookies.

SameSite attribute

In order to protect the websites from Cross-Site Resource Forging (CSRF) attacks, browsers like Chrome and Firefox enforce defaults for the SameSite attribute. This would mean that if you wish to enable cookies for cross-site requests from your website, you’ll need to explicitly set the attribute to do so.

Set-Cookie: visited=true; SameSite=Lax

Let’s take a look at the different options available for this cookie attribute:

  1. Strict — used to restrict the cookie usage within the same-site context.

For e.g. If my-user.github.io sets a cookie in the client. When a route like images/my-photo.png lying in the same subdomain, is accessed from within the website, the cookie will be sent with the requested image to the server. On the other hand, when accessing a route example-github.io/images/your-photo.png from within my-user.github.io , the cookie will not be sent with the requested image.

The cookie is sent with the request within the same domain. Cookie is not sent along the cross-site request to my-photo.png t
A cookie is not sent along with the cross-site request to my-photo.png through example-github.io.

There is an exception to the above rule — a cookie with an attribute SameSite=Strict always sends the cookie with the request except during top-level navigation to the website via a link or an external source.

For e.g. my-user.github.io accessed via a link or an email will not send the cookie with the request to my-user.github.io/my-photo.png

The cookie with my-user.github.com accessed via a link or an email will not send the cookie with the request to my-photo.png
Cookie accessed via a link or an email will not send the cookie with the same-site requests

2. Lax — This is where Lax comes into the picture. It allows sending the cookie on initial navigation into the website from a third-party context for e.g. a link or an email. This is a less restrictive same-site policy than Secure.

By default, the browsers now enforce a default same-site policy Lax to prevent CSRF attacks. A CSRF attack can be done by malicious websites by sending untrustworthy data in a cookie sent along with the request which can make your website vulnerable to outside attacks.

For e.g. if a malicious website tries to access a cross-site resource /images/my-photo.png and updates the cookie values while sending the request to the server. In some cases, this can be devastating.

Cookie is sent with the request to /images/my-photo.png in the browser accessed from a link in an email.
The cookie is sent with the request to the resource accessed from an email.

3. None — the cookie is sent with the request to the server despite the same-site or not. To enable cross-site cookies, the same-site attribute needs to be explicitly set to None.

Here’s an example demonstrating this — A flag visited is set in the cookie on user.github.io. A request made for accessing an image hosted at my-user.github.io/images/my-photo.png sends the cookie along. The same cookie is also sent with the request example.github.io/image/my-photo.com from within the same subdomain user.github.io

Cookie is set in the client and sent with request from `my-user.github.com` and `example-user.github.com`
A Cookie is set in the client and sent with a request from `my-user.github.io` and `example-user.github.io`

Tldr;

  • Depending on which requested resource, same-site or cross-site, a cookie is sent with, it’s of two types namely, first-party and third-party.
  • In order to limit forwarding the cookies with the request, the browsers allow for setting a cookie attribute called SameSite which defaults to a value of Lax which prevents sending cross-site cookies.
  • In order to enable cross-site cookies, the SameSite attribute needs to be set to None.

--

--

Rachita Bansal

Software Engineer @ Microsoft | Full-Stack | Data viz| Node.js | React | GraphQL | UI/UX