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 1. This type of cookie has three modes:
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.
Noneattribute must be accompanied by the
Strict– Causes the browser to not include cookies in any cross-site requests. This means
XHRwill all make requests without the SameSite
Strictcookies attached. Even if the user clicks on a link to
example.com/resource, their cookies are not included.
Lax– The only difference between
Laxmode allows cookies to be added to requests triggered by top-level navigations. This makes
Laxcookies 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.openthat allows the attacker to maintain a reference to the
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 2 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.
Anyone interested in deploying this mechanism in web applications should take a careful look at this web.dev article.