Webにおいて、あらゆる場面でブラウザを個別に判別するために、Cookieは重要な仕組みとなっています。
ECサイトをはじめとする会員制サイトでは、認証が行われた状態であるかどうかの判別にCookieに保存された識別情報で判断する方法が基本になっています。ところが、最近Cookieの仕組みそのものに対する風当たりが強くなってきており、各ブラウザなどで、仕様変更を余儀なくされつつあります。
その流れで、Google ChromeではVer.80から、順次”SameSite Cookie”のデフォルト値を”none”から”Lax”に変更するとしており、Cookieを使用したサイトで動作に影響を受ける可能性が出てきています。
具体的に影響を受ける可能性の高いサイトとして、まず1つのサイト、もしくはサービスでサブドメインを含む複数のドメインを使用して動いているかどうかが基準となります。
SameSite Cookieは、言い換えれば”サードパーティから配布されたCookie”、つまり、閲覧中のサイトのドメインとは違うドメインのサイトから配布されたCookieが対象になるため、Cookieを発行したサイトのドメインと、Cookieを読み取るサイトのドメインが同一であれば、今回はこの変更の影響を受けません。この場合は現時点では安心できそうです。
気をつけなければいけないのは同一サイトで2つ以上のドメインを使用し、かつ同じCookieの値を2つ以上のドメインから読み取って使用する場合と、サイトのコンテンツを、外部のサイトやブログに埋め込むことができる仕組みを提供していて、その仕組みの中でCookieを使用している場合です。
上記のようなシステムの場合で、SameSiteの設定がChrome 80以降の規定値であるLaxになった場合、次のような影響が出る場合があります。
top-level navigation(*1) で、且つ GETメソッドであれば、他のドメインへのリクエストであってもクッキーをセットします。
例えば、Aサイトでログイン中だった場合に、Bサイト上に用意されたAサイトへのリンクをクリックした場合、ログイン状態でページの遷移が行われます。
POSTメソッドを使ったフォーム、imgタグ、iframe、XMLHttpRequests などによる他ドメインへのリクエストにはクッキーはセットされません。
Strict より条件が緩い(lax)です。
通常は、こちらを使うことになるでしょう。
HTTP クッキーをより安全にする SameSite 属性について (Same-site Cookies) – ラボラジアン
つまり、SameSite=Laxになった場合、URLバーのURLが変化する形での別ドメインへGETメソッドで転送される場合を除き、異なるドメイン間でのCookieの共有は不可能になります。
最初にも説明した通り、Cookieはブラウザを個別に識別するのに必要になる情報なので、これが共有できなくなるとユーザーの識別が不能になり、ドメインが切り替わった時点でログアウトやデータがリセットされてしまう、といった挙動になってしまう場合が出てきます。
ただし、上記の例はあくまでSameSite設定を明示していない場合です。SameSite=noneを明示的に指定し、かつ一定の条件を満たしていれば従来通りCookieを共有できそうです。
ChromeのSameSiteの規定値変更による対応は、一度ではなく、徐々に対象範囲を拡大する方式のようなので、直ちに大きな影響を受けないかもしれませんが、すぐに対策を取らないと大規模な不具合につながってしまう可能性があります。
早めの対応が必要になりそうです。
