Recently I got to know about SameSite cookie attribute which is used to mitigate the CSRF attacks. AFAIK SameSite attribute for cookies is implemented in Chrome and some other browsers. Since I'm Using Tomcat server to deploy my web apps, I have raised a discussion with Tomcat dev to see whether they have plans to support this in an upcoming release. They said that if the spec work had not stopped and/or the protection it offered was more complete, then they can consider supporting SameSite Cookie. Here I want to clarify below-mentioned questions.

  1. Since the draft is expired [1], what is the Current status of SameSite cookie?
  2. Will it be a standard solution?

[1] [https://www.ietf.org/archive/id/draft-ietf-httpbis-rfc6265bis-02.txt]

2 Answers 2


SameSite cookies are here to stay.

They were available for a long time in Chrome (since v51) and more recently got implemented in Firefox.

Making cookies samesite protect against a whole range of CSRF vulnerabilities. It protects against BREACH, a compression side channel attack that can steal a cookie by forging a lot of authenticated requests. It protects against some client-side Spectre attacks, where the response to a cross-origin request is read using speculative execution vulnerabilties.

The spec is still being worked on. For example, how strict samesite cookies should behave in redirects is not entirely clear.

I would currently advise everybody to set samesite=Lax on all cookies. It offers a reasonable security advantage without breaking things or being too much work. Using samesite=Strict cookies gives more security, but may break some functions on your site.

Server software needs to give the option to set the samesite attribute to either Lax or Strict. That part of the spec is very stable and it would not be premature to offer that. For example, PHP is planning to add samesite to their setcookie function.

Also, I would expect that you could use samesite cookies even if Tomcat doesn't implement it, if you create your own Set-Cookie headers.

Update: Chrome is planning to make all cookies SameSite=Lax by default, which you can disable by setting SameSite=None.

  • 1
    Strict semantic implies that if you use say Google to find the home page of a site (that isn't a google.com site, that includes YouTube), the page is fetched as if in Incognito mode, then if you reload the page, it's re-fetch in normal mode? Users might find that very confusing.
    – curiousguy
    Jun 28, 2018 at 18:32
  • @curiousguy that matches my understanding of tools.ietf.org/html/… . So you should either use SameSite=Lax, or the more sophisticated approach described in this section.
    – sourcejedi
    Aug 23, 2019 at 10:12
  • Even Lax mode is going to break stuff. There are plenty of sites that do completely legitimate cross-origin POST requests. It's certainly less common (and probably less preferred) than cross-origin GET, but there are some things you really can't do with a GET (upload a file, send anything you don't want showing up in logs, etc.) and even requests between two subdomains that are under the same parent (like "account.foo.com" and "www.foo.com") are considered cross-origin.
    – CBHacking
    Aug 23, 2019 at 18:09
  • 1
    To clarify: account.foo.com and www.foo.com are cross-origin, but they are still the same site. SameSite=Lax cookies would be sent on requests between these. For an actual cross-site POST request, this should definitely be marked SameSite=None.
    – rowan_m
    Nov 25, 2019 at 14:09

To add more to @Sjoerd answer.

As far as I know, SameSite cookie cannot protect against a whole range of CSRF vulnerabilities. If website has a GET base CSRF bug, attacker can still exploit it easily, SameSite cookie is good against POST base CSRF though.

Also, It protects against a lot of side-channel attacks, which using sending requests cross-site with cookies and measure time different.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .