SameSite Cookie属性とSynchronizerトークンパターン
最近、ほとんどのブラウザがSameSite cookie属性にサポートを追加して、CSRF攻撃を防止しています： https://www.owasp.org/index.php/SameSite
CSRF攻撃を防ぐためにシンクロナイザートークンパターンを実装する必要があるかどうかを質問しますか？ https://www.owasp.org/index.php/Cross-Site_Request_Forgery_（CSRF）_Prevention_Cheat_Sheet＃Synchronizer_Token_Pattern
SameSiteは、シンクロナイザトークンパターンと少なくとも同じCSRF攻撃を防ぎますか？
SameSiteオプションがstrictとlaxであることは知っています。おそらく、lax値を使用します。
追加
設定（ https://caniuse.com/#search=Samesite ）をサポートするブラウザでSameSite設定のみ（シンクロナイザトークンパターンなし）を使用する場合、CSRF攻撃は可能ですか？
可能な攻撃シナリオは何ですか？
（質問はXSS攻撃に関連しておらず、CSRF攻撃にのみ関連しています）
サポートされている場合、CSRF攻撃を防ぐためにシンクロナイザートークンパターンを実装する必要がありますか？
No！ただし、あなた絶対には、状態変更アクションにGETのようなリクエストメソッドを使用しないでください。
SameSiteは、シンクロナイザトークンパターンと少なくとも同じCSRF攻撃を防ぎますか？
Yes！ 3番目のドメインからの要求へのCookie（SameSiteフラグ付き）の送信を省略しているため、Cross-Site要求はauthenticated リクエスト。したがって、これはCSRFを防ぎます。ただし、SameSite Cookieがすべての種類のGET要求をブロックするわけではありません。たとえば、リンク事前レンダリング要求はいくつかの例外であり、おそらくリストに追加されません。したがって、状態変更アクションにGETリクエストを使用しないことは非常に重要です。
設定をサポートするブラウザでSameSite設定のみ（シンクロナイザトークンパターンなし）を使用する場合、CSRF攻撃は可能ですか？
短い答え：いいえ
Cookieを上書きすることが可能です。ただし、これによってCSRFに対して脆弱になるわけではありません。 Cookieを上書きするには、攻撃者が値を入力する必要があります。この場合、彼/彼女がすでにCookieの値を知っている場合、彼/彼女はすでに被害者のアカウントへのアクセス権を持っています。ただし、 On-Site Request Forgery （コメントで述べたように）は常に例外です。
可能な攻撃シナリオは何ですか？
他の脆弱性と組み合わせない限り、何もありません。
編集：
プラグインが開始したリクエスト（Flash、PDFなど）は、期待どおりに動作しない場合があります。 SameSite Cookieが含まれる場合と含まれない場合があります。したがって、ATMでは、SameSite Cookieとともにトークンを使用します。