CSRFトークンの仕組みがどうしても理解できないです。
CSRF対策として「CSRFトークンをフォームに埋め込み、サーバで照合することで不正リクエストを防ぐ」とあります。

Cookieはブラウザが自動送信してしまいCSRFが成立してしまうことは理解できました。
また、SameOriginPolicyをブラウザに設定しても他のオリジンからのセッションIDの読み取りは防げても送信は防げないからCSRFは成立してしまうことも理解できます。

一方でCSRFトークンも最終的にはブラウザが保持しているので「攻撃サイトが偽フォームを送信した際に、ブラウザが保持しているCSRFトークンも一緒に送られてしまうのではないか？」と思っています。

チャットGPTに聞いてもSameOriginPolicyによってトークンの送信は防げると言っていましたが、
「なぜブラウザが持っているCSRFトークンは攻撃サイト経由のリクエストでは送信されないのか」
が理解できません。
SameOriginPolicyでセッションIDの送信は防げないのになぜCSRFトークンは防げるのでしょうか？
Same Origin Policyとの関係も含めて教えていただけると助かります。

この投稿は投稿者により削除されました。(2026.06.23 17:32)

ご質問の通り、攻撃サイトが偽フォームを送信するとブラウザのCookieは自動的に一緒に送信されてしまいます。しかし、攻撃者は「Cookieに保存されたトークンの値」や「HTMLのBodyに埋め込まれたトークンの値」を読み取ることはできません。この読み取りを攻撃者から遮断する働きをするのがSameOriginPolicyです。これにより、攻撃者は正しいトークンを知ることができずCSRFを防ぎます。なので、「SameOriginPolicyによってトークンの送信は防げる」という表現は正しいようで正しくない、というのが回答です。

Cookieの送信はブラウザが自動で行っており、これはURLにアクセスさせたりフォームを送信させたりするだけで簡単に発生します。

一方、CSRFトークンは通常レスポンスボディ（HTML内のhiddenフィールドやJavaScript変数など）に含まれており、これをブラウザが自動送信する機能はありません。

そのため攻撃者は、正しいCSRFトークンの値を指定したうえでリクエストを送信させる必要があります。

しかし、CSRFトークンの値は正規サイトのレスポンス内に存在し、Same Origin Policyによって攻撃サイトからその内容を読み取ることはできません。

結果として攻撃者は正しいCSRFトークンを取得できず、サーバ側の照合に失敗するため、CSRF攻撃は成立しなくなります。

要するに、Cookieが自動送信されることがCSRFの原因であるため、Cookie以外の攻撃者が取得できずブラウザも自動送信しない値（CSRFトークン）を別途用意して正当なリクエストかどうかを判定するのがCSRF対策です。

さやかさん
むぐむぐさん
お二方とも返信ありがとうございます

私が何かを勘違いしているみたいです

ブラウザの設定のSameOriginPolicyで別オリジンからは中身が読み取れないことは理解しました

ちなみに私が思っているCSRFの攻撃の流れは次のとおりです

1 被害者が攻撃対象のWebサーバにログインする
   このときにサーバから送られてきたHTTPレスポンスによってセッションID（Cookie）やCSRFトークンがブラウザに保存される

2 被害者が攻撃者の用意したWebサイトにアクセスする

3 攻撃者のWebサイトに埋め込まれた仕掛けによって被害者のブラウザから攻撃対象のWebサーバへリクエストが送信される
   ブラウザは保存しているセッションID（Cookie）とCSRFトークンを使い攻撃対象のWebサーバにアクセスする

4 結果として設定変更などの不正な操作が実行されてしまう

これだと攻撃が成立してしまうのではと思います

CSRFトークンはブラウザが自動送信する機能がないとありますが、逆に正規のアクセスの場合はどのようにブラウザがHTTPリクエストのボディにCSRFトークンを付与しているのでしょうか？
ユーザが操作してトークンを付与するのは現実的ではないと思います

理解が悪くて申し訳ありません

1の際にブラウザ内のCookie領域にセッションIDを保存します。
CSRFトークンはサーバから返されたレスポンス内のDOMに埋めこまれており保持している状態にはなりますが、Cookieのようにブラウザの専用領域へ保存され自動送信されるものではありません。

実際に設定変更などを行う際は、設定変更画面のレスポンス内に以下のような形で埋め込まれています。
formの例：
<form action="/test" method="POST">
  <input type="hidden" name="csrf_token" value="X7A92B3K">
  <input type="submit">
</form>

そのため、ユーザーが設定変更ボタンなどを押下すると、CSRFトークンもサーバへ送信されます。


攻撃者は正しいCSRFトークンの値を知らないため、その値を埋め込んだformを用意することができません。
結果として、ブラウザによって自動送信されるCookieは送信させることができても、正しいCSRFトークンは送信させることができず、サーバ側の照合に失敗するため攻撃は成立しません。

※CSRFトークンの送信はjavascriptを利用するもの等、別の方法もあるので上記はあくまで一例です。

むぐむぐさん

返信ありがとうございます！

やっと理解できた気がしました！
つまり
攻撃者は
formの例：
<form action="/test" method="POST">
  <input type="hidden" name="csrf_token" value="◯◯◯">
  <input type="submit">
</form>
は作れるけど
vlaueの中身のX7A92B3KはSameOriginPolicyによって読み取れないため攻撃は成立しないってことでしょうか？

とても腑に落ちました！
ありがとうございます。