First Party CookieのSameSite属性を試す。

Security Web

一昔前に話題になっていたので、いまさらながらCookieのSameSite属性について調べた。 First Party Cookieと、Third Party Cookieがあるが、今回はFirst Party Cookieの確認。 *1

一言でSameSiteの設定の影響について説明するなら、他のドメインからのアクセスがあったときのCookie送信の振る舞いが変えるための設定。

CookieのSameSite属性の基本(First Party Cookie)

例えば、mydomain.comのサイトでSameSiteを設定すると、他のドメインxxxx.comからmydomain.comにアクセスがあったときに、mydomain.comで設定されているCookieが送信されるかどうかが変わる。

SameSiteの設定を変えると、どのように変わるかは、以下の制約が厳しい順にみていく。

  • Strict
  • Lax
  • None

SameSite=Strict

他のドメインからアクセスがあった場合、一切Cookieが送信されなくなる。

具体的には、aタグとかのリンクで、mydomain.comにアクセスした場合でも、最初のアクセスではCookieは送信されないということ。リロードすればCookieは送信される。

SameSite=Lax

他のドメインからPOSTでアクセスがあった場合、Cookieが送信されなくなる。 他のドメインからGETでのアクセスの場合は、Cookieは送信される。

具体的には、formのドメインとpost先のドメインが違うような場合に、Cookieは送信されないということ。

Strictとは違って、aタグとかのリンクで、他のドメインからアクセスした場合は影響はない。

SameSite=None

他のドメインからのアクセスであっても、常にCookieは送信される。

SameSite設定の影響についての考察

さて、騒がれていたのはChrome80以降では以下のように仕様が変わるとのこと。

  • SameSite=Laxがデフォルトになる。
  • SameSite=Noneを設定する場合は、Secureの設定が必須になる。

で、NoneからLaxにある日突然切り替わると困るのは、クロスドメインでPOSTをやっている場合ということになる。

これどういうときに困るかというと、Webアプリを運用する場合だと、domain1.comのAPIサーバをdomain2.comにしていて、domain1.comからdomain2.comにPOSTでアクセスするようなケースあたりが考えられそう。セッションIDをCookieに保存していると一時的にセッションが切れてしまうわけでめんどくさい。

あとは、決済関係とかは他のドメインからpostされることも多そうなので影響大きそう。

多少不便になるケースもあるが、Laxを設定しておけば、CSRF対策として一定の効果はありそう。一方で、CSRFトークンとかで対策されているやん？という話もあるが。

*1:最近の話題だからか、徳丸本にも記載なかったし、Real World HTTPについては記載が誤っていたり結構混乱した。