The SameSite cookie attribute was first drafted in 2016. It defines under which circumstances a cookie should be sent to the server, putting cookies into three different classes:

SameSite=None

Send the cookie whenever a request is made to the cookie domain. A cookie without the SameSite attribute will currently be handled as if it was sent with SameSite=None.

Note: Google announced to start enforcing usage of the SameSite attribute in Chrome "later this year", meaning it will handle cookies without the SameSite attribute as if they were sent with SameSite=Lax.

SameSite=Lax

Like None, but only send the cookie with GET requests in a first-party context (meaning the URL in the address bar matches the cookie domain). Do not send it with AJAX requests to another site, with requests from iframes of other sites, image requests to another site etc. For the same site, AJAX/iframe/image/etc requests will continue to work unchanged.

SameSite=Strict

Like Lax, but 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, but with an AJAX request to the cookie domain that is triggered from the cookie domain.

Strict is a good idea e.g. for an CSRF cookie.

What this means for web development

Chrome moving to SameSite=Lax as default forces web developers to handle this change. Considering its market share, other browser vendors will move along.

In order to keep your application unchanged, you can just add SameSite=None to all cookies you're setting (e.g. with a Rails middleware). This is a passable way for stale application that you do not want to modify.

However, a better way is to embrace the change. The SameSite attribute offers new possibilities of controlling cookie behavior. Furthermore, SameSite=Lax should not break most applications. Some breaking use cases to watch out for:

Rendering in an iframe

When your application (or parts of it) are rendered inside an iframe, SameSite=Lax will prevent your cookies to be sent along (unless the iframe is embedded on its own domain). If you need tracking or authentication cookies in an iframe context, set SameSite=None on these cookies.

Cross-domain API

When you're offering an API that is queried a) from the browser b) from various domains, SameSite=Lax will prevent your cookies to be sent along. Set SameSite=None on cookies you need to receive on the API.

Non-GET requests with AJAX

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.

Note that setting SameSite=None on the single cookie you're storing all data in eliminates the advantages of the attribute. Prefer to split your cookies depending on the context they're used in.

Resources

• Prose spec of the SameSite attribute, illustrated
• A sceptical view on the topic
• RFC

Check out our new e-book:

Growing Rails Applications in Practice

Learn to structure large Ruby on Rails codebases with the tools you already know and love.

Learn more