SameSite Cookies

October 1, 2020

SameSite cookies are one of the most impactful modern security mechanisms for fixing security issues that involve cross-site requests. This mechanism allows applications to force browsers to only include cookies in requests that are issued same-site ¹. This type of cookie has three modes: None, Lax, and Strict.

SameSite Cookie Modes #

The following SameSite cookie modes are available:

• None – Disables all protections and restores the old behavior of cookies. This mode is not recommended.

  important

  The None attribute must be accompanied by the Secure flag ¹.

  ---

  1. SameSite cookies explained, link ↩︎

• Strict – Causes the browser to not include cookies in any cross-site requests. This means <script src="example.com/resource">, <img src="example.com/resource">, fetch(), and XHR will all make requests without the SameSite Strict cookies attached. Even if the user clicks on a link to example.com/resource, their cookies are not included.

• Lax – The only difference between Lax and Strict is that Lax mode allows cookies to be added to requests triggered by top-level navigations. This makes Lax cookies much easier to deploy since they won’t break incoming links to your application. Unfortunately, an attacker can trigger a top-level navigation via window.open that allows the attacker to maintain a reference to the window object.

Considerations #

Strict cookies provide the strongest security guarantees, but it can be very difficult to deploy Strict same-site cookies in an existing application.

SameSite cookies are neither bulletproof ² nor can they fix everything. To complement this defense strategy against XS-Leaks, applications should consider implementing other, additional protections. For example, COOP can prevent an attacker from controlling pages using a window reference even if SameSite cookies in Lax mode are used.

Deployment #

Anyone interested in deploying this mechanism in web applications should take a careful look at this web.dev article.

References #