Why setting cookie SameSite=Lax mitigate CSRF

Jeff posted on  (updated on )

In the world of the web, the cookie is a piece of data that will be automatically attached to each request made by the browser. This piece of data usually includes a user’s identifiable information and is used to achieve functionality like keeping a user logged in between navigation.

To understand why setting one of the cookie’s many attributes: SameSite to Lax, would help mitigate (not full protection) Cross-site request forgery(CSRF), let’s break it down into 3 questions:

  1. What is CSRF
  2. What is SameSite=Lax? What are other options?
  3. Why Lax mitigates CSRF

1. What is CSRF?

CSRF1 stands for Cross-Site Request Forgery. It is a type of malicious exploit of a website or web application where unauthorized requests are submitted from a user that the web application trusts.

How to perform such attacks?

Web application trusts a user by most commonly checking the cookie, as it usually carries Session ID. The browser will automatically attach cookies to each request (GET/POST/DELETE, etc.) made to the web application. Normally, each request is made by the user knowingly, but attackers have many ways to trick the victim's browser into sending malicious requests without the user's approval.

For example, on a blogging website, for a logged-in user to delete a post, the user would click the "Delete" button on the blogging website, and the browser will send out a DELETE request to http://blog.com/post/xxx, with the user's cookie attached. Now, the attacker wants to have a user (let's call him Bob) unknowingly delete one of Bob's posts on the website. The attacker could build a web page that, whenever someone opens the page, sends out the same DELETE request. Then, the attacker would trick Bob into visiting his web page, by means such as phishing email. When Bob clicks the malicious link to the attacker's web page, its browser will send out the DELETE request, automatically attaching Bob's session info in the cookie, and Bob's post will be deleted without his approval.

2. What is SameSite=Lax

An HTTP Cookie 2 can have many attributes3, SameSite4 being one of them that is relevant to our topic here. It controls the browser's behavior when sending requests cross-site.

What is considered Same Site/Cross Site?

The definition for Site is here: https://web.dev/articles/same-site-same-origin#site

Same Site simply means the Site of two URL is the same, Cross Site means the Site of two URL is different.

How to use cookie's SameSite attribute?

The possible attribute values are:

  1. "Strict"
  2. "Lax" (default behavior)
  3. "None"

Let's see what each value does.

For "None", this cookie will be attached to both the same site and cross-site requests.

For "Strict", this cookie will be attached only to the same site requests.

For "Lax", it's a mix of 2 extremes. It means that the cookie is not sent on cross-site requests, such as on requests to load images or frames, but is sent when a user is navigating to the origin site from an external site (for example, when following a link).

3. Why Lax mitigates CSRF

As you can probably tell, CSRF exploits the browser's behavior to attach cookies automatically. But SameSite=Lax tells the browser to NOT attach cookies if the source website is not the same as the target website. Thus, making sure requests are only coming from legitimate websites.

Footnotes

  1. https://en.wikipedia.org/wiki/Cross-site_request_forgery ↩

  2. https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies ↩

  3. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#attributes ↩

  4. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#samesitesamesite-value ↩