CSRF対策概論
文書番号：2610.00003
要旨
CSRF（Cross-Site Request Forgery）は、利用者のブラウザが自動送信する認証情報を悪用し、利用者の意図しない操作を対象システムに実行させる攻撃なのだ。本稿では、攻撃の仕組みと成立条件を説明したうえで、CSRFトークン、送信元検証、Fetch Metadata、SameSite、カスタムヘッダーによる防御を比較するのだ。公開仕様と公式文書に基づき、各方式が依拠する条件と限界を整理し、認証構成に応じた適用設計、実装、検証へ議論を進めるのだ。防御の有効性は、正規操作を維持しつつ、攻撃者が誘発したリクエストによる状態変更を防げるかで評価するのだ。掲載する設計案と試験項目は、個別システムでの実証結果ではないのだ。
1. 序論
Webアプリケーションは、ログイン後のリクエストに付随する認証情報から利用者を識別するのだ。しかし、その情報がブラウザから自動送信される場合、リクエストが利用者の意図した操作に由来するとは限らないのだ。CSRF対策の課題は、認証済みのリクエストについて、攻撃者のページから誘発された操作を排除することなのだ。1
本稿は、HTTPとCookieの基本を理解する開発者・運用者を対象に、CSRFの原理、防御方式、適用条件を体系的に整理する解説なのだ。2026年10月27日時点で参照したブラウザ仕様、OWASP、認証プロトコルとフレームワークの公式文書を根拠とするのだ。通常のブラウザに別サイトからリクエストを送らせる攻撃を中心に扱い、XSSや端末侵害との境界は第7章で述べるのだ。
2. CSRFの原理と成立条件
2.1 攻撃の仕組み
Cookieでログイン状態を維持する業務Webを例に考えるのだ。利用者は業務Webにログインした後、攻撃者が管理する別サイトを閲覧するのだ。そのページが業務Webへのフォーム送信を誘発すると、ブラウザはCookieの送信条件に従って認証Cookieを付与するのだ。業務Webが追加の検証を行わなければ、利用者本人の権限で更新処理が実行されるのだ。12
この攻撃では、攻撃者が認証Cookieの値を知る必要はないのだ。被害者のブラウザが、その値を対象システムへ送信するのだ。Cookieが実際に付与されるかは、SameSite属性、送信方法、ブラウザの制限などに依存するのだ。12
2.2 攻撃の成立条件
CSRFの成立可否は、保護対象の操作、認証情報の送信、攻撃者が構成できるリクエスト、通信経路、防御の検証を組み合わせて評価するのだ。
| 確認対象 | 確認する内容 |
|---|---|
| 操作対象 | 登録、変更、削除、承認、権限設定などの保護すべき処理があるか |
| 認証の運搬 | Cookieなどの認証情報がブラウザから自動送信されるか |
| リクエストの構成 | 攻撃者が必要なURL、メソッド、パラメータを用意できるか |
| 到達経路 | 被害者のブラウザから対象システムに接続できるか |
| 防御の検証 | トークンや送信元の検証が、処理の実行前に機能するか |
2.3 同一オリジンポリシーとCORS
ブラウザの同一オリジンポリシーは、別オリジンのページ内容や応答の読み取りを制限するのだ。一方、別オリジンへのリンク遷移や通常のフォーム送信は、一般に可能なのだ。攻撃者が応答を読めなくても、サーバー側で更新が完了すればCSRFの目的は達成されるのだ。3
CORSも、設定しただけでフォーム送信を一律に止める仕組みではないのだ。プリフライトを必要としないリクエストでは、応答の読み取りが拒否されても、リクエスト自体は送信され得るのだ。サーバーが処理を実行した後の読み取り制限は、更新操作の防止にならないのだ。4
2.4 攻撃者モデル
HTTPクライアントを自作すれば、Referer、Origin、Sec-Fetch-Siteなどの値を自由に指定できるのだ。しかし、そのクライアントには、被害者のブラウザが保持する認証情報が自動的に移るわけではないのだ。
通常のCSRFでは、攻撃者が操作するのは別サイトのページなのだ。被害者のブラウザ自体を自由に改造する権限は前提としないのだ。WebページのJavaScriptによるヘッダー操作には、ブラウザの制約が適用されるのだ。15
| 攻撃者が持つ能力 | 可能なこと | 評価する問題 |
|---|---|---|
| 別サイトのページを操作する | 被害者のブラウザに遷移やフォーム送信を誘発する | 通常のCSRF |
| 自分のHTTPクライアントを操作する | 任意のヘッダーや本文を送信する | 認証・認可、APIの不正利用 |
| 正規サイト内でスクリプトを実行する | 正規ページの権限でリクエストを生成する | XSSと、その後の操作 |
| 被害者の端末やブラウザを支配する | ブラウザの保護機構や利用者の操作を迂回する | 端末侵害、セッション悪用 |
したがって、自分のHTTPクライアントでヘッダーを偽装できることだけでは、CSRF防御を回避できる証明にならないのだ。試験では、被害者の認証状態を維持したブラウザから攻撃が成立するかを確認するのだ。
3. CSRFの防御方式
3.1 防御の基本原則
CSRF対策は、攻撃の成立条件のいずれかを満たせなくするように設計するのだ。具体的には、攻撃者が用意できないトークンを要求する、ブラウザが示す送信元や通信文脈を検証する、認証Cookieの送信を制限する、フォームでは生成できないリクエスト形式を必須にするといった方法があるのだ。16
いずれの方式でも、保護対象の処理を実行する前に検証を完了させるのだ。GET・HEAD・OPTIONSなどの安全なHTTPメソッドでは業務状態を変更しないことを前提とするのだ。メソッドをPOSTへ変えるだけでは、別サイトからのフォーム送信を排除できないのだ。37
3.2 同期トークン方式
サーバー側でセッションを管理するアプリケーションでは、Synchronizer Token Patternが選択肢となるのだ。サーバーは予測困難なトークンを生成し、利用者のセッションに対応させて保持するのだ。正規ページには、フォームの隠し項目やJavaScriptが取得する値としてトークンを渡すのだ。更新時には、受信したトークンとセッション側の値を照合するのだ。7
概念上の処理は次のとおりなのだ。
正規画面の取得
サーバーがセッションに対応するトークンを画面へ渡す。
業務操作の送信
ブラウザが認証Cookieと、本文または専用ヘッダー内のトークンを送る。
サーバー側の検証
認証・認可を確認する。
トークンを現在のセッションと照合する。
必要な検証がすべて成功した場合だけ、業務処理を実行する。
認証Cookieとは別の場所に、攻撃者のページが用意できない値を要求する点が重要なのだ。トークンをCookieに入れて自動送信させるだけでは、この条件を満たさないのだ。攻撃者が自分のセッションで取得したトークンも、被害者のセッションでは通過できない設計にするのだ。7
トークンを必須としたエンドポイントでは、未送信や不一致を拒否するのだ。Originが一致していることを理由にトークン検証を省略するなど、後付けの救済条件を設けないのだ。これは、本稿で推奨するトークン方式の判定方針なのだ。
実装にはフレームワーク標準機能を優先するのだ。例えばSpring Securityは、期待するCSRFトークンをHttpSessionに保持する機能を提供しているのだ。セッション切れや再ログイン時の挙動も、採用した実装に合わせて確認するのだ。8
3.3 署名付きダブルサブミット方式
トークンの状態をサーバーに保存しにくい構成では、署名付きダブルサブミット方式を検討できるのだ。Cookieと本文または専用ヘッダーの対応を検証し、さらにサーバーの秘密鍵によるHMACを検証するのだ。HMACは共有秘密鍵を使うメッセージ認証方式であり、公開鍵による電子署名とは異なるのだ。6
トークンは現在のログインセッションに結び付けるのだ。単純にCookieと本文の文字列が一致するだけの方式では、Cookieを注入できる攻撃者への耐性が不足するのだ。署名付きという名称だけで判断せず、セッションとの結び付けを確認するのだ。6
3.4 Origin・Refererによる送信元検証
送信元検証は、ブラウザが付与するヘッダーと、サーバーが定義した許可先との一致を確認する方式なのだ。通常のWebページのJavaScriptからは、Originを任意に設定できず、Refererの直接の自由設定も制限されるのだ。Refererはポリシーによって省略や情報の縮減が起こるため、値の一致と欠落時の扱いを分けて設計するのだ。59
Originは、通信を起点とするオリジンを表すのだ。オリジンはスキーム、ホスト名、ポートの組み合わせであり、URLのパスやクエリを含まないのだ。サーバーは、受信した値を許可済みオリジンと比較するのだ。Originが欠落する場合や、nullになる場合もあるのだ。10
比較は、URLを解析したうえで正確に行うのだ。例えば、https://app.example.comを許可していても、https://app.example.com.attacker.exampleは別のオリジンなのだ。期待する値は構成情報から決めるのだ。プロキシ配下では、外部公開URLと内部ホスト名の違いを整理するのだ。受信したHostや転送ヘッダーを無条件に許可判定の基準へ採用しないのだ。
Refererを使う場合も、原則としてオリジン単位で検証するのだ。操作権限はサーバー側の認可処理で判定するのだ。プライバシーポリシーによってパスが省略される場合もあるのだ。9
送信元検証を主たる防御にする場合は、欠落時の扱いまで設計するのだ。Origin: nullやヘッダーなしを正常な同一オリジンとみなす方式では、別の検証根拠が必要となるのだ。本稿では、送信元を確認できない場合はトークンなどの代替検証へ進み、それも成立しなければ拒否する構成を推奨するのだ。明示的に許可外のOriginが届いた場合は拒否し、欠落時の代替検証と区別するのだ。
3.5 Fetch Metadataによる通信文脈の検証
Sec-Fetch-Siteは、リクエストの起点と送信先の関係をブラウザが示すヘッダーなのだ。Sec-で始まるヘッダーは、通常のWebページのJavaScriptから任意に設定できないのだ。5オリジンとサイトは異なる概念なのだ。例えば、https://portal.example.comとhttps://app.example.comは別オリジンだが、同じサイトとして扱われるのだ。11
次表は、通常の業務更新エンドポイントに適用する保守的な判定例なのだ。認証と認可は別途必要となるのだ。
| 値 | 解釈 | 判定例 |
|---|---|---|
same-origin | 同一オリジンを起点とする | この検証段階を通過させる |
same-site | 同じサイト内の別オリジンを含む | Originの許可リストなどで追加確認する |
cross-site | 別サイトを起点とする | 原則拒否（正規連携には専用経路） |
none | アドレス入力など、通常のページ起点とは異なる | 更新操作では別の検証を要求する |
| 欠落・未知の値 | このヘッダーからは判定できない | 他方式で検証し、検証できなければ拒否 |
同じ親ドメイン配下にあるという理由だけで、すべてのサブドメインを信頼しないのだ。部門別アプリケーションや委託先管理のホストが混在する場合は、その管理境界を許可条件へ反映するのだ。
Fetch Metadataは、仕様上、潜在的に信頼できるURLへの通信に付与されるのだ。一般的な社内HTTPサイトで、HTTPSサイトと同じ送信挙動を前提にしてはならないのだ。また、リダイレクト経路も値の判定に影響するのだ。11
共通基盤へ導入する場合は、各経路でヘッダーが保持されることを確認するのだ。GoのCrossOriginProtectionはヘッダー利用型の実装例だが、両ヘッダーがない通信を許可する仕様を持つのだ。既存機能を採用する際も、その欠落時動作が対象環境の要求に適合するかを評価するのだ。Goの実装はGET・HEAD・OPTIONSも許可するため、これらのメソッドで業務状態を変更しない設計が前提なのだ。12
3.6 SameSiteによるCookie送信制御
SameSite=Strictは、クロスサイト通信でのCookie送信を厳しく制限するのだ。Laxは、一定のトップレベル遷移では送信を許すのだ。Noneはクロスサイト送信を許可する設定であり、Secure属性が必要となるのだ。2
Laxが許すGET遷移で更新を実行する構成は避けるのだ。同一サイト内の別オリジンも攻撃起点になり得るため、SameSiteと同一オリジンの制限を同一視しないのだ。既定値に依存せず、必要な属性を明示するのだ。一部ブラウザでは、属性未指定時の既定動作に、発行直後のCookieをPOSTで送信する例外があるのだ。2
なお、HttpOnly付きCookieもブラウザから送信されるのだ。この属性はJavaScriptからの読み取りを制限するものであり、単独のCSRF対策にはならないのだ。2
正規のクロスサイト通信が必要な構成では、Cookieの用途ごとに送信条件を決めるのだ。認証連携における適用例は第4.3節で扱うのだ。
3.7 カスタムヘッダーとCORSによるAPI保護
APIが専用のカスタムヘッダーを必須とすれば、通常のHTMLフォームから同じリクエストを作ることはできないのだ。別オリジンのJavaScriptから送る場合は、CORSのプリフライト対象となるのだ。許可していない起点からの本リクエストを、ブラウザ側で止める構成を作れるのだ。54
この方式では、ヘッダーの有無をサーバーが必ず検証するのだ。CORSの許可先は正規のフロントエンドに限定するのだ。任意の受信オリジンを許可する実装や、ヘッダーなしで同じ更新を実行できる別経路を設けないのだ。
Content-Typeの違いも確認するのだ。JSON専用の想定でも、text/plainなどを同じ更新処理として受け付けると、フォームから到達できる経路が残り得るのだ。プリフライトを必要とする条件を、サーバー側でも一貫して要求するのだ。54
3.8 重要操作の追加認証と承認
権限付与や送金などでは、WebAuthnによる追加認証や取引単位の承認を組み合わせられるのだ。WebAuthnは、認証器による暗号学的な証明を検証する仕組みなのだ。通常のトークン検証とは異なる信頼の根拠を追加できるのだ。13
ただし、再認証の成功だけで、変更対象や金額まで承認されたことにはならないのだ。承認結果を対象操作と結び付け、承認後の内容変更や別操作への流用を防ぐのだ。端末侵害まで想定する場合は、重要な操作内容を信頼できる表示経路で確認する設計も必要となるのだ。14
4. 防御方式の適用設計
防御方式を選ぶ際は、アプリケーションの認証方式と正規の通信経路を確認するのだ。本章では、自動送信される認証情報、ネットワークの公開範囲、認証連携という三つの観点から、第3章の方式を適用する条件を整理するのだ。
4.1 認証情報の送信方式
JavaScriptがAuthorization: Bearer ...を明示的に付与し、そのトークンだけで認証するAPIは、Cookieを自動送信する構成と条件が異なるのだ。攻撃者のページが対象のトークンを取得できなければ、通常のフォーム送信に認証情報を付けられないのだ。15
ただし、JWTなどのトークンをCookieに格納して送信する場合は、この区別を適用できないのだ。Cookie認証へのフォールバックがあるAPIも、該当する経路を調べるのだ。ブラウザ専用のバックエンドであるBFF（Backend for Frontend）の構成では、ブラウザとBFF間の認証方式を確認するのだ。BFFから後段APIへの通信にBearerトークンを使っていても、前段のCookie認証に対する評価は残るのだ。
これは、CSRF回避のためにアクセストークンをブラウザの保存領域へ移すことを推奨するものではないのだ。保存方式の変更では、XSSによるトークン窃取リスクも評価するのだ。15
Windows統合認証も、ブラウザが認証情報を自動送信する構成なのだ。Microsoftは、Windows認証を使うエンドポイントにもCSRF対策が必要と説明しているのだ。15
4.2 ネットワークの公開範囲
公開範囲は、攻撃者が直接接続できる範囲を変えるのだ。CSRFでは被害者のブラウザを通信の起点にするため、社内限定という条件だけで防御を省略できるとは判断しないのだ。外部サイトを閲覧できる社員のブラウザが、社内Webにも接続できる構成は評価対象となるのだ。実際の成立可否は、ブラウザのネットワーク制限や端末ポリシーを含めて確認するのだ。315
以下は、認証情報の自動送信と操作内容を基準にした設計判断なのだ。
| 利用場面 | 公開Webでの判断 | 社内限定Webでの判断 |
|---|---|---|
| Cookie認証を使う更新・承認処理 | CSRF防御を設ける | 同じ基準を適用する |
| Cookieを使わないWindows統合認証 | ブラウザが認証情報を自動送信する構成を確認する | 社内SSOであっても防御対象とする |
| 静的ページや実質的に閲覧だけの機能 | CSRFチェックの一律適用は通常不要 | 通常は不要（管理機能・設定変更は別評価） |
| 認証済みユーザーの不正操作 | 認可と業務ルールで制御する | 内部不正や侵害端末についても同様に制御する |
| スクレイピング、SQLインジェクション | Refererではなく、それぞれの攻撃に対応する対策を用いる | 同左 |
閲覧専用という判断は、業務データだけでなく、権限、公開範囲、ログイン状態なども変えないことを前提とするのだ。ログイン処理自体のCSRFは、第4.3節の認証フローとして扱うのだ。7
4.3 SSOの認証フローと業務セッション
SSOは複数のシステムに認証結果を連携する仕組みなのだ。例えばOIDCでは、認証基盤による利用者の認証結果をクライアントが検証するのだ。その後の業務リクエストをどのように認証するかは、アプリケーションの構成によるのだ。16
SAMLやOIDCのログイン後に業務WebがセッションCookieを発行する構成では、そのCookieを利用する処理を評価するのだ。認証プロキシがCookieを受け取り、バックエンドへ利用者情報を転送する構成でも、ブラウザ側の認証情報が自動送信される点に注目するのだ。
認証連携を扱う理由は、認証基盤から戻る正規のクロスサイト通信と、認証後の業務操作とで、適用する検証が異なるためなのだ。
OIDCやSAMLでは、認証基盤から業務Webへブラウザを戻す通信が発生するのだ。認証基盤と業務Webが別サイトなら、正常な通信もクロスサイトになるのだ。SAMLのHTTP-POST Bindingなどを、業務更新用の一律遮断ルールに含めると認証が失敗し得るのだ。1617
OIDC/OAuthでは、state、nonce、PKCEを、それぞれの役割に従って用いるのだ。stateは認証要求と応答の対応付けに利用できるのだ。OIDCのnonceは認証要求とIDトークンを結び付けるのだ。PKCEは認可コードと、その交換に必要な検証値を結び付けるのだ。1618
RFC 9700は、認可サーバーのPKCE対応を確認したクライアントについて、PKCEによるCSRF防御を利用できるとしているのだ。OIDCのnonceで防御する場合や、ユーザーエージェントに安全に結び付けた単回使用のstateを使う場合も、対応する検証を実装するのだ。各パラメータの存在だけで合否を決めず、開始時のブラウザとの結び付けと、受信時の検証を確認するのだ。これらは認証コールバックの保護であり、認証後の業務APIへ自動的に適用されるものではないのだ。18
SAMLでは、信頼する発行者の署名、対象となるサービス、宛先、有効期間、再利用の防止などを検証するのだ。SP起点の認証では、InResponseToと開始時のブラウザセッションを使い、応答を対応する認証要求に結び付けるのだ。IdP起点の未要求応答では、その対応付けが利用できないのだ。OWASPは、この方式にログインCSRF防御上の制約があると説明しているのだ。17
SSOコールバックを共通ルールの例外にする場合は、対象パスとメソッドを限定するのだ。その経路では、SSOライブラリによるプロトコル検証を必須とするのだ。
クロスサイトPOSTの受信時に認証要求との対応付け用Cookieが必要になる構成では、そのCookieと通常の業務セッションCookieを区別し、必要範囲だけSameSite属性を調整するのだ。
5. 実装と変更管理
実装では、各エンドポイントの認証方式、採用する検証、例外、検証不能時の動作を一貫させるのだ。既存の防御を変更する場合も、新方式が担う保護を確認してから切り替えるのだ。本章では、その具体例として送信元検証の変更を扱うのだ。
5.1 標準機能と検証範囲
フレームワークの標準機能を採用する場合は、トークンの保存方式、送信元検証、適用対象を一体として確認するのだ。例えばRefererチェックを変更する際は、その検証が独立した追加対策なのか、標準防御の必須構成要素なのかを区別するのだ。トークンが存在するという事実だけでは判断できないのだ。
例えばDjango 5.2の標準CSRF処理は、トークン検証に加えてOriginを検証するのだ。HTTPSでOriginがない場合は、厳格なReferer検証を行うのだ。この検証は、サブドメインによるCookie操作などへの保護にも関係するのだ。Refererのエラーを解消するためにミドルウェア全体を無効化すると、トークンの検証まで失われるのだ。19
確認すべき対象は、実際に使用しているバージョン、保存方式、検証順序、適用外の経路なのだ。
5.2 送信元ヘッダーの欠落と縮減
ブラウザ変更の後にエラーが生じても、Refererヘッダー全体の欠落とは限らないのだ。例えばstrict-origin-when-cross-originでは、クロスオリジン通信のRefererがオリジンだけになる場合があるのだ。以前の完全なURLを期待する実装は、その変化で不一致になるのだ。9
調査では、同じ操作について変更前後のリクエストを比較するのだ。ブラウザの送信内容と、WAF・プロキシ通過後の受信内容も区別するのだ。確認対象は、メソッド、URL、Origin、Referer、Sec-Fetch-Site、Cookie属性、トークン検証結果なのだ。証跡に認証情報やトークンの実値を残さないのだ。6
特定のブラウザ製品やバージョンを原因とする判断は、再現試験と仕様の確認に基づいて行うのだ。
5.3 既存防御からの移行
以下はアプリケーションの制約に応じた移行案の選定基準なのだ。
| 現状・制約 | 移行案 | 採用条件 |
|---|---|---|
| セッションに結び付いたトークン検証が全更新経路で有効 | 独立したRefererチェックの除外を検討する | 既存実装がRefererを前提とする部分まで確認できる |
| アプリケーション改修が可能 | 標準のCSRFトークン機能を導入する | フォームとAPIの両方に検証を適用できる |
| 個別改修が難しく、HTTPSとブラウザを統制できる | Fetch MetadataとOrigin検証を共通基盤へ導入する | 正規連携、欠落時処理、基盤の迂回経路を管理できる |
| JavaScriptからのみ利用するAPI | カスタムヘッダー必須化と限定的なCORSを採用する | ヘッダーなしの代替経路が存在しない |
| ヘッダーが安定せず、アプリケーションも改修できない | 経路の修正や製品側の対応を検討する | 無検証の許可へ変更せず、残存リスクを個別管理する |
複数方式を組み合わせる場合は、各方式の役割を固定するのだ。トークン必須方式とヘッダー方式を、通信の都合に応じて無制限に切り替えないのだ。正規のクロスオリジン通信が必要な経路には、事前に定義した専用ポリシーを適用するのだ。
業務更新、閲覧、SSOコールバック、外部連携を分けて適用条件を定義するのだ。GETで更新する機能があれば、メソッド名だけで保護対象から外さず、先に設計上の問題として扱うのだ。7
移行では、既存防御を維持したまま新方式の判定ログを取得するのだ。正常系と攻撃系の試験を通過した後、新方式の遮断を有効にするのだ。最後に旧Refererチェックを除外するのだ。共通基盤で保護する場合は、バックエンドへの直接到達が迂回経路にならない構成を確認するのだ。
これらは、防御の空白期間を作らないための導入手順なのだ。
6. CSRF対策の有効性評価
6.1 評価方法と試験項目
評価では、正規画面からの操作と、別サイトから誘発したリクエストとを比較するのだ。利用者が認証済みのブラウザを用い、Cookieの送信条件やヘッダーの付与を含めて確認するのだ。
次表は、本稿の防御構成を確認するための試験例なのだ。対象システムの許可を得た環境で実施するのだ。全項目を一つの方式へ機械的に適用するのではなく、採用した判定条件に対応させるのだ。
| 試験 | 確認する結果 |
|---|---|
| 正規画面から通常の更新を行う | 認証・認可と所定のCSRF検証を通過する |
| トークンを未送信または不正値にする | トークン必須経路で更新が実行されない |
| 別セッションのトークンを流用する | セッション結合型の方式で拒否される |
| Refererを送らない正規操作を行う | 設計に応じて代替検証で処理されるか、拒否される |
| 別サイトからフォーム送信を行う | 被害者の認証状態があっても更新されない |
| 攻撃側ページでRefererを省略して送信する | 欠落を利用した検証回避が成立しない |
Origin: nullとなるブラウザ文脈で送信する | 不明な送信元を無条件に信頼しない |
| 信頼していない兄弟サブドメインから送信する | same-siteだけを根拠に更新を許可しない |
| SSOの正常なコールバックを実行する | 正規の認証フローが維持される |
| SSO応答の対応付けを壊す、または再利用する | 採用プロトコルの検証で拒否される |
| セッション切れ、再ログイン、複数タブを試す | 想定したエラー処理と再取得手順で動作する |
| 共通基盤を通らない経路を調べる | 同じ更新処理へ無防御で到達できない |
CSRFトークンがセッション単位の場合、同じトークンを複数回使用できること自体は不備ではないのだ。単回使用は、取引単位の承認など、その性質を要求する方式で試験するのだ。814
試験結果はHTTPステータスだけで判断しないのだ。対象データ、監査ログ、後続処理を確認し、拒否されたリクエストで状態変更が起きていないことを確かめるのだ。リダイレクトを含む操作は、最終応答までの各リクエストを記録するのだ。
6.2 評価結果と運用記録
点検資料には、対象エンドポイント、認証情報の送信方式、採用したCSRF防御、例外、欠落時の処理、試験結果を記載するのだ。SSO部分と業務操作部分は、別の評価対象として管理するのだ。
防御機能を変更する場合は、変更する処理の範囲と、変更後に残る検証を示すのだ。代替策が未検証の場合は、対策済みと扱わず、期限と責任者を伴うリスク対応として管理するのだ。
ガイドラインの記載例は次のとおりなのだ。
ブラウザが自動送信する認証情報を利用する保護対象操作には、CSRF防御を適用するのだ。防御方式ごとに、許可条件、検証不能時の処理、例外経路を定義するのだ。認証コールバックには、採用プロトコルに適合する専用の検証を適用するのだ。防御機能を変更する場合は、正常系と攻撃系の受入試験により、処理の許可・拒否が設計どおりであることを確認するのだ。
7. 防御の前提と限界
7.1 防御の信頼基盤
トークン方式は、攻撃者が被害者のセッションで有効な値を取得・生成できないことを前提とするのだ。一方、送信元や通信文脈の検証は、ブラウザがヘッダー操作を制限することと、サーバーが許可条件を正しく定義することを前提とするのだ。両者は異なる信頼の根拠を持つのだ。576
方式の評価では、単に「クライアント由来の値か」を問うよりも、第2.4節の攻撃者モデルに照らして、有効な値を攻撃者が用意できるかを判断するのだ。Goのヘッダー利用型防御のように、欠落時の動作を含む実装上の条件まで確認する必要があるのだ。12
7.2 XSS・クライアント側CSRF・端末侵害
CSRFトークンの検証成功は、利用者が画面を読み、その操作を理解して承認したことまでは証明しないのだ。正規ページでXSSが成立すれば、トークンを利用したリクエストも生成され得るのだ。19
正規JavaScriptがURLなどの外部入力から操作先を組み立てる実装では、攻撃者がその入力を操作し、正規スクリプトに不正なリクエストを生成させるクライアント側CSRFにも注意を要するのだ。6
端末やブラウザ自体が侵害された場合は、本稿で扱う通常のCSRFとは攻撃者の能力が異なるのだ。ブラウザの制約を前提とする検証だけで評価を完結させず、端末の保護やセッション管理を含めて対処するのだ。
8. 結論
CSRFは、認証情報の自動送信と、外部のページから誘発できるリクエストとの組合せによって成立するのだ。対策には、トークン、送信元・通信文脈の検証、Cookie送信制御、APIのリクエスト形式の制約があり、それぞれ異なる成立条件に働きかけるのだ。
方式の選定では、認証情報の送信経路と正規通信の要件を明らかにし、すべての保護対象操作に検証を適用するのだ。SSOの認証コールバックや既存のReferer検証の変更は、この設計原則に基づいて扱う個別の適用場面なのだ。導入先での有効性は、正規操作の継続と、不正なリクエストによる状態変更の防止を試験して確認するのだ。
参考資料（出典）
参照日は2026年10月27日なのだ。継続更新される文書の仕様を採用する際は、導入先の製品バージョンとの一致を確認するのだ。