最低工数

• 常時 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 している暇があったら他のことをしたほうが良さそう。