Chrome 80 (2020年2月予定) からは挙動が変更され、SameSite 属性がない (なにも対応していない場合) は SameSite=Lax の挙動がデフォルトになる。かなり厳しい制約が増えるので対応必須。
また、既存の挙動に戻すためには SameSite=None を指定する必要があるが、SameSite=None は Secure 属性が必須になる。
ということでいずれかが最低限必須
- https 化 と Secure 属性
- SameSite=Lax で問題ないサイトづくり
最低工数
- 常時 https 化する
- Secure 属性と SameSite=None 属性をつける
既に https 化されているなら最も手軽で追加の検証がいらない。
→ 今まで通りの挙動。CSRF 耐性は特になく、セキュリティは向上しないが不具合はでない
ちょっとは頑張れる
- SameSite=Lax 属性をつける
→ ほぼ今まで通りだが、外部からのフォーム POST など、CSRF に繋がりそうなケースで挙動がかわり安全になる。XHR や iframe でも cross-site の場合はデフォルトでクッキーが送られなくなるので、対応のうえ全体で再度QAが必要
もっと頑張れる？
SameSite=Strict にすると、あらゆる外部サイトからのページ遷移のときにクッキーが送信されなくなる。最初に開くと必ず非ログイン状態になり、そのあと遷移するとログイン状態が復活したりする。ユーザー体験上、Strict をそのまま既存のセッションクッキーに適用するのは困難。
副作用が発生するクッキーだけを Strict クッキーに分けるような設計をすれば活用できるが、サイトのページ遷移から見なおす必要がある。
個人の見解では Strict を使うケースはないんじゃないかと思う。SameSite=Strict は銀の弾丸ではなく、アプリケーションの問題は CSRF だけではない。結局、総合的に他の施策も必要なので、SameSite=Strict している暇があったら他のことをしたほうが良さそう。
