CSRF攻撃の同じ生成元ポリシー？
私の理解では、デフォルトですべてのブラウザで同じOriginポリシー（SOP）がデフォルトで有効になっています。つまり、Webブラウザは、最初のWebページに含まれているスクリプトが2番目のWebページのデータにアクセスすることを許可しますが、両方のWebページが同じオリジンを持っている場合に限られます。
私の質問は、SOPが設定されているため、CSRFトークンを使用してCSRF攻撃を個別に処理する必要があるかどうかです。ほぼすべてのWebサイトがCSRFトークンの実装によってそれを軽減していると思いますSOPが設定されているときになぜ必要なのですか？
CSRFを防ぐために、関連する別のCookie「SameSite = strict」がこの blog に表示されます。私には、デフォルトでブラウザから提供されるSOPのように見えます。それは本当に必要ですか？
同じOriginポリシーでは、認証済みallのクロスサイト相互作用は防止されません。 具体的に 、読み取りは禁止されていますが、クロスOriginの書き込みと埋め込みは通常許可されています。
- 通常、クロスオリジン書き込みが許可されています。例は、リンク、リダイレクト、フォーム送信です。
- 通常、クロスオリジン埋め込みが許可されています。
- 通常、クロスオリジン読み取りは許可されていませんが、埋め込みによって読み取りアクセスが漏洩することがよくあります。
許可されているケースの多くは、ウェブが適切に機能するために重要です。
Chrome は間もなくデフォルトのsamesite=laxに変更されます。これにより、たとえば、クロスサイトPOST Cookieを使用したリクエスト（および画像やiframes）。
ただし、リンクへのアクセスなど、他の「書き込み」タイプのアクションは妨げられません。そのため、GETベースのCSRFは、samesite=laxを使用してもオプションのままです（samesite=strictを使用しない場合でも）。
このため、および追加のセキュリティ機能を持つクライアントに依存するべきではないため（ユーザーはChrome以外のブラウザを使用するなど）、各サイトでCSRF防止を採用する必要があります（samesite=strictを使用して、 CSRF防止。ただし、サイトでユーザーがリンク、フォーム、画像などのHTMLのサブセットを投稿/制御できる場合、またはオープンリダイレクトなどの他の脆弱性がある場合は、機能しなくなる可能性があります）。