flawopen.com/CSRF/GET リクエスト
GET に CSRF トークンは必要ですか？
GET がデータ取得だけを行うなら、サーバー状態を変更すべきではなく、通常 CSRF トークンも不要です。ブラウザー、クローラー、プレビュー、埋め込みリソースは、意図的なクリックなしに GET を送ることがあります。削除や購入などには非安全メソッドを使い、Cookie 認証された状態変更を CSRF から保護してください。状態を変更する旧式 GET は依然として脆弱であり、移行中は一時的な防御が必要です。
GET を安全なメソッドに保つ理由
RFC 9110 は GET を安全と定義しています。クライアントは状態変更を要求しません。安全とはログ記録などの付随的なサーバー側効果がないという意味ではありません。GET は冪等でもありますが、別の性質です。ブラウザー、先読み、クローラー、リンクプレビューは、ユーザーが意図的に操作しなくても安全なリクエストを送ることがあります。他サイトの <img src="..."> も、ユーザーの Cookie 付き GET を発生させる可能性があります。エンドポイントが削除や設定変更を行うなら GET の意味論に違反し、通常のページコンテンツから実行されるおそれがあります。
状態変更リクエストに CSRF 対策を適用
- ✓GET、HEAD、OPTIONS では要求された状態変更を行わず、変更には POST、PUT、PATCH、DELETE を使う
- ✓Cookie 認証された非安全メソッドをフレームワークの CSRF 対策または検証済みトークンで保護し、SameSite と Origin/Fetch Metadata 検証を追加
- ✓状態変更 GET は HTTP メソッドの意味論上の欠陥として扱う。一時的な CSRF 対策を追加し、操作を移行して URL から秘密情報を取り除く
GET の CSRF に関する FAQ
脆弱な状態として扱います。一時的にサーバーで検証する CSRF 防御（例：Synchronizer Token と、利用可能な場合の Origin または Fetch Metadata 検証）を必須にし、キャッシュと Referer を監査したうえで POST、PUT、PATCH、DELETE に移行します。トークンをクエリ文字列に入れないでください。URL は履歴、ログ、Referer 情報に残ることがあります。トークン検証はメソッドの意味論を満たすまでの移行措置です。