WebアプリケーションにおけるCSRF（Cross-Site Request Forgery）は、ログイン中のユーザーに意図しない操作を強制させることで、財務取引やアカウント操作など重大な被害を引き起こします。この記事では、CSRFの仕組みを丁寧に解説し、現代のブラウザ仕様やフレームワークに対応した具体的な対策を紹介します。技術者だけでなく運用者にも役立つ内容です。
目次
CSRF の仕組み 対策 を理解するための基本的な定義と特徴
CSRF（クロスサイトリクエストフォージェリ）は、ユーザーがログインしているWebサイトに対して、別サイトから操作を強制する攻撃手法です。攻撃者が作成した罠サイトなどを経由して、銀行振込や設定変更などのHTTPリクエストが、意図せず正規ユーザーのクッキー付きで送信されると、サーバー側はそれを正規の操作と誤認します。
この攻撃が成立するためにはいくつかの条件があります。ユーザーが対象サイトにログイン中であること、ブラウザが自動でクッキーを付与すること、そしてリクエストが状態を変える操作であることが必要です。GETではなくPOSTなど、状態変更系が標的となることが一般的です。
CSRF攻撃とは何か
CSRFとは、ユーザーがログインしているWebサービスにおいて、その意図しないリクエストを第三者が偽装して送信させる攻撃です。ユーザー自身が操作したかのように見えるため、見た目には判別できないケースがあります。Cookie の自動送信仕様を悪用するのが典型例です。
攻撃者はフォーム偽装や画像タグの挿入などの手段を使い、ユーザーの意思とは無関係にサーバーへ要求を送ります。被害例としては、パスワード変更、アカウント乗っ取り、商品の購入などがあります。サーバー側が、そのリクエストが正当であるかどうかを厳密に確認できないのが問題です。
XSS との違いと相互作用
XSS（クロスサイトスクリプティング）は攻撃者がクライアント側でスクリプトを実行させることで、情報漏洩や操作を直接制御できる脆弱性です。一方 CSRF は、ユーザーのブラウザが既に持っている認証情報を利用して、不正なリクエストを第三者が強制させる点が異なります。
ただし、XSS が成立すると CSRF 対策（トークンなど）も同一オリジン内で読み取られてしまう可能性があり、CSRF と XSS の対策は密接に関連しています。つまり CSRF 対策のみでは不十分で、XSS の予防も含めたセキュリティ設計が求められます。
なぜ CSRF が脆弱性として恐れられるのか
CSRF は認証済み状態を持つユーザーの権限をそのまま悪用できるため、被害が拡大しやすいのが特徴です。ユーザーが積極的に操作しなくても、罠サイトを訪れる程度で被害が生じるおそれがあります。
また、管理者が対象となるケースではシステム全体が乗っ取られるリスクもあります。さらに、ユーザーに通知が行かないまま操作が行われることが多く、発覚が遅れることが被害拡大の要因となります。
最新情報を反映した CSRF 対策の具体的な手法
CSRF の対策としては複数の手法を組み合わせることが推奨されています。現代のブラウザ仕様やWebフレームワークは、SameSite Cookie、CSRF トークン、Origin／Referer チェックなどの対策をデフォルトで備えるものが多く、これらを適切に設定することで高い防御効果が得られます。
特に、ブラウザの Cookie 属性である SameSite を適切に利用し、POST や状態変更系操作を非シンプルリクエストにする設計や、Fetch Metadata のヘッダーを使ってリクエストの発生元を判定する仕組みが注目されています。
SameSite Cookie の利用
SameSite 属性は Cookie がクロスサイト環境で自動的に送信されるかを制限するものです。値には Strict、Lax、None があり、Strict は最も制限が強く、Lax は GET のトップレベルナビゲーションなどに限定して送信されます。None はクロスサイト送信を許可しますが Secure を併用する必要があります。
近年のブラウザでは、SameSite の指定がない Cookie はデフォルトで Lax とみなされるようになっており、指定漏れによる CSRF のリスクが軽減されてきています。しかし Lax では POST リクエストなど状態変更系の防御が弱くなる場合があり、リスクを理解したうえで設定することが重要です。
CSRF トークン（アクセストークン／フォームトークン）
CSRF トークンは、サーバーが発行する予測不能な値をフォームやリクエストヘッダーに含めることで、正規のユーザーによる操作かどうかを検証する手法です。典型的にはフォームの hidden フィールドや、フロントエンドからの POST リクエスト時に追加ヘッダーで送信されます。
トークンはセッションとひも付ける、毎リクエストごとに変更する、利用後に無効化するなどの運用が望ましく、古いトークンの使い回しを防ぐ設計が重要です。またトークンが Cookie と同じく JavaScript で読み取れるようになっている場合、XSS 脆弱性が存在すると情報漏洩のきっかけになるため注意が必要です。
Origin／Referer ヘッダー検証
重要な操作を扱うルートでは、HTTP リクエストの Origin または Referer ヘッダーを確認して、リクエストが自サイトまたは信頼できる発信元から来ているかを検証するのが簡便かつ強力な対策です。これにより、外部サイトからの偽造リクエストがブロックされます。
ただし、Referer ヘッダーはプライバシー設定などによって省略されることがあるため、Origin の確認を主体とする設計が望ましいです。特に POST／DELETE／PUT 等の状態変更系の操作に対してこの検査を導入します。
Fetch Metadata やカスタムヘッダーの活用
最新のブラウザでは Fetch Metadata ヘッダー（例：Sec-Fetch-Site）を用いてリクエストの発信元コンテキストがどのようなものかを判定できるようになっています。これにより、クロスサイトからの状態変更系操作を自動的に制限できる設計が可能です。
加えて、カスタムヘッダーを要求することで「非シンプルリクエスト」扱いとし、CORS の仕様やプリフライトチェックを必須とすることが、防御の強化につながります。API と SPA（シングルページアプリケーション）構成では特に有効です。
Webフレームワークとサーバー設計における組み込み対策
多くのWebフレームワークは CSRF 対策をあらかじめ備えており、デフォルトで有効化されている場合があります。開発者はその機能を正しく利用し、不要なカスタマイズや設定ミスを避けることが安全性を高めるカギです。
また、サーバー設計としては、状態変更系のルートを整理し、認証レベルや利用者の権限チェックなどを厳格に行うことで、万一 CSRF 攻撃が成立しても被害を限定できるような設計が望まれます。
主要フレームワークにおけるデフォルト設定
多くのフレームワークでは CSRF トークンの生成と検証が組み込まれており、SameSite 設定やOrigin チェックも含まれているものが増えています。これらのデフォルト設定を無効化したり手動で書き換えたりすると、弱点が生じるので注意が必要です。
フレームワークのドキュメントやリリースノートを確認し、最新バージョンでどのような CSRF 防止機能が提供されているか把握することが重要です。設定ミスによる脆弱性が過去に多数報告されています。
セキュアな API 設計と SPA／BFF の活用
API とフロントエンドを分離した SPA（シングルページアプリケーション）構成では、バックエンド側にセキュリティレイヤを設けた BFF（Backend For Frontend）パターンが有効です。BFF を通じて API 呼び出しを集中管理し、CSRF 防止の処理を一元化できます。
また、API は通常非シンプルリクエストを要求する設定にし、カスタムヘッダーや Content-Type を JSON にするなどして、クライアント側での偽造を困難にします。この設計により、不用意な GET による操作を避けることができます。
限界・誤解しやすい点と注意すべき実務トラップ
CSRF 対策には限界や誤解しやすい部分が存在します。SameSite=Lax の挙動誤解や Referer の省略、XSS の併発などは、しっかり知っておかないと防御設計に抜けができやすい部分です。また、利用者のブラウザ設定やプロキシなど外部要因も影響します。
実務では、これらの注意点を踏まえ、多層防御（Defense in Depth）を採ることが安全性を確保する上で不可欠です。以下に代表的な誤解とトラップを紹介します。
SameSite=Lax の誤解
SameSite=Lax は GET のトップレベルナビゲーションに対する制限が緩いため、状態変更系の操作が GET を使っている設計だと、攻撃者に利用される可能性があります。また、古い仕様やブラウザ互換性の問題で SameSite 指定が意図通り動かない例があります。
さらに、一部のブラウザや HTTP セキュリティポリシーでは Referer の省略やヘッダー改変が発生するため、SameSite=Lax のみで防御を完結させるのは危険です。
Referer や Origin チェックの落とし穴
Referer ヘッダーはユーザーのプライバシー設定や HTTPS から HTTP の遷移時に省略されることがあります。Origin ヘッダーは比較的信頼性が高いですが、古いブラウザや特定のリクエスト形態では付与されないことがあります。
また、Origin をホワイトリスト方式で許可したドメインを多くしすぎると、その管理が追いつかず、誤って悪意のあるドメインを含めてしまうリスクがあります。監査とレビューが必要です。
XSS 脆弱性との関連性
CSRF 対策としてトークンを使っていても、XSS 脆弱性があればトークンが盗まれる可能性があります。JavaScript から読み取れる Cookie にトークンを入れる設計は、XSS の被害を拡大させるリスクがあるため、HttpOnly や適切な CSP（Content Security Policy）との併用が望まれます。
攻撃者がスクリプトを挿入できる状況では、CSRF よりも XSS のほうが深刻です。したがって、CSRF 対策と並行して XSS を防ぐ設計を行うことがセキュリティ上の鉄則です。
導入手順とチェックリスト：現場で使えるガイド
CSRF 対策を実際に導入する際には、計画と検証が不可欠です。以下のチェックリストに沿ってステップを進め、広範なテストを実施することで脆弱性を未然に防ぐことができます。
初期設計の段階で考慮すべきこと
まず最初に、アプリケーションのどの操作が「状態を変える操作」かを洗い出します。ログイン・登録・更新・削除といった機能が該当します。それぞれのエンドポイントに対して CSRF 対策の適用が必要かを定義し、設計ドキュメントに記録します。
また、認証形式（Cookie ベース／トークンベース／OAuth など）によって必要な対策が異なるため、使用する仕組みを確認し、フレームワークのデフォルトのセキュリティ機能が有効かどうかを確認します。
実装時のベストプラクティス
実装にあたっては、CSRF トークンはセッション毎かリクエスト毎に生成し、フォームの hidden フィールドや AJAX／Fetch のヘッダーに埋め込む設計にします。同時に、SameSite＝Strict を可能な限り使用し、必要なCookieには Secure 属性や HttpOnly 属性も設定します。
Origin／Referer チェックを状態変更系のリクエストで必須とし、ただし Referer が省略されるケースを想定して Origin を主要な検査対象とすることが望ましいです。SPAや API 系はプリフライトリクエストやカスタムヘッダーを活用して非シンプルリクエストにする設計が効果的です。
テストと確認のステップ
対策が適切に働いているかを検証するために、自作やサードパーティのペネトレーションテストを利用します。罠サイトを模したテストや、不正な Referer／Origin を含むリクエストを送ってブロックされるか確認することが重要です。
さらに、ブラウザ互換性（SameSite のデフォルト動作、ヘッダーの扱い）や、HTTPS 化による Secure 属性の動作、Cookie スコープ（ドメイン、パス）の設定などもチェックします。ユーザーから報告がないから安全とは限りません。
まとめ
CSRF はユーザーの認証状態を悪用し、意図しないリクエストを強制することで発生する攻撃であり、被害が発覚しにくい点が厄介です。仕組みを正しく理解し、現代のブラウザ仕様やフレームワークの機能を活用することが重要です。
具体的には、SameSite 属性を適切に設定すること、CSRF トークンや Origin／Referer チェックを導入すること、非シンプルリクエストとカスタムヘッダーを活用すること、そして XSS の防止も併せて行うことが効果的です。複数の防御層を設けることで、想定外のリスクにも備えることができます。
Webアプリケーションの脆弱性を防ぐために、設計段階からセキュリティを意識し、定期的に見直しとテストを行うことが、安全なシステムを維持する鍵となります。
コメント