TL;DR Most web applications do not require action on this. SameSite=None
(old browser default) will continue to work, and SameSite=Lax
(new Chrome default,
gradually rolled out
Show archive.org snapshot
) is an even better default for cookies. Set SameSite=Strict
only for extra security in special cases (see below). If your application is rendered in an iframe (e.g. a video player or some news stream), you need to configure its relevant cookies as SameSite=None
.
The SameSite
cookie attribute targets cross-origin requests. It defines under which circumstances a cookie should be sent to the server, putting cookies into three different classes:
Send the cookie whenever a request is made to the cookie domain, be it cross-origin or on the same site, from the page or from an iframe. This is how cookies have behaved the last decades.
Only send the cookie in a first-party context (meaning the URL in the address bar matches the cookie domain). Do not send it with the following cross-origin requests: non-GET, AJAX, iframe, image requests etc. It saves the user from cross-site request forgery.
Only send the cookie if the request was initiated from the cookie domain. The cookie will not be sent if the user e.g. opens a link from an email. Strict
is a good idea e.g. for an CSRF cookie.
A cookie without the SameSite
attribute will currently be handled as if it was sent with SameSite=None
. However, Google
announced to start enforcing usage of the SameSite
attribute in Chrome in February 2020
Show archive.org snapshot
, meaning it will handle cookies without the SameSite
attribute as if they were sent with SameSite=Lax
.
If your application is running on a single domain without any cross-origin communication, you're fine: nothing to do.
Chrome moving to SameSite=Lax
as default forces web developers to handle this change. Considering its market share, other browser vendors will move along.
A good default is SameSite=Lax
. In fact, you can add SameSite=Lax
to all set cookies and it will run just fine in the most cases. Some breaking use cases to watch out for:
When your application (or parts of it) are rendered inside an iframe, SameSite=Lax
cookies will not be sent along with requests of the iframe (unless the iframe is embedded on its own domain). If you need cookies in an iframe context, set SameSite=None
to disable the protective behavior.
When you're offering an API that is queried from browsers on various domains, SameSite=Lax
will prevent your cookies to be sent along. Set SameSite=None
on cookies you need to receive on the API.
A Lax
cookie will not be sent with POST
, DELETE
, OPTIONS
or any other request. If you need an authentication cookie on these, you must either make the cookie SameSite=None
or SameSite=Strict
.
A few web browsers have issues:
SameSite=None
SameSite=None
SameSite=None
like SameSite=Strict
SameSite=None
like SameSite=Strict
In config/initializers/session_store.rb, add the options secure: true, same_site: :strict|:lax
. To set :none
you need Rack 2 (i.e. Rails 5).
Rails 6.1 will set SameSite=Lax;
on default.
Custom cookies are set with cookies[:cookie_name] = 'value'
or = { value: 'value', path: '/path' }
. Use the latter version and add a same_site
option, i.e.
cookies[:my_cookie] = { value: 'my-value', same_site: 'None' }
Make sure you're using at least 2.2.0. Set a cookie with options secure: true, samesite: 'strict|lax|none'
.
To test the effect of the new Chrome behavior on your site or cookies you manage, you can go to chrome://flags in Chrome 76+ and enable the “SameSite by default cookies” and “Cookies without SameSite must be secure” experiments.