「XSS」と「CSRF」。どちらもWebサイトの弱点を突く攻撃で、名前も頭文字も似ているため、試験勉強では混同しやすい用語です。
この記事では、2つの攻撃の違いを 何が動くのか・誰が被害を受けるのか・どう防ぐのか の3点で比べます。IPA（独立行政法人 情報処理推進機構）の公開資料にもとづいて確認した内容です。
IPAの情報セキュリティマネジメント試験シラバス（Ver.3.2）では、サイバー攻撃手法の用語例として、この2つを含む複数のWeb関連の攻撃が挙がっています。アプリケーションセキュリティの項目には「クロスサイトスクリプティング対策」も挙がっています。（2026年10月9日確認）
結論：「何が動くか」で見分ける
2つの違いは、一言で言うとこうなります。
- XSS（クロスサイトスクリプティング）：攻撃者が仕込んだスクリプトが、利用者のブラウザで動く
- CSRF（クロスサイトリクエストフォージェリ）：ログイン中の利用者のブラウザから、意図しない要求が本人の名前で送られる
XSSは「悪いプログラムが動く」攻撃、CSRFは「本人の操作として扱われる」攻撃です。この区別を最初に頭に入れておくと、あとの対策も整理しやすくなります。
XSSとは：サイトの画面にスクリプトを混ぜる攻撃
XSSは、Webアプリケーションが利用者の入力値などをそのまま画面に出力してしまうことで起きます。IPAの資料では、攻撃者がページにスクリプトを埋め込める状態になる脆弱性として説明されています。
特徴的なのは、被害の向く先です。IPAの資料によると、影響はウェブサイト自体ではなく、そのページを閲覧している利用者に及びます。
起きうる被害（IPAの整理）
- 本物のサイト上に偽の画面を表示され、フィッシングのように重要な情報を入力させられる
- cookieにセッションID（ログイン中の本人だと示す番号）が入っていると盗まれ、利用者になりすまされる
- cookieに個人情報が入っていると、その情報が漏れる
狙われやすい機能
入力内容を画面に出す機能です。IPAの資料では、入力内容の確認画面、入力内容を再表示するフォーム、検索結果、エラーメッセージ、コメント欄などが例に挙げられています。
CSRFとは：本人のふりをして要求を送らせる攻撃
CSRFは、ログイン中の利用者のブラウザに、本人が意図していない要求を送らせる攻撃です。サイト側は、その要求が外部のページから来たものだと見分けられないと、そのまま処理してしまいます。
IPAの資料では、cookieなどで利用者のログイン状態を管理しているサイトで、ブラウザが自動で送る情報をもとに要求を受け付けてしまうことが原因とされています。攻撃者は外部のサイトに罠を仕掛け、利用者がそれを開くと、ログイン中のサイトへ要求が送られます。
起きうる被害（IPAの整理）
- ログインして使うサービスでは、不正な送金、意図しない商品購入、退会など
- 内容を書き込めるサイトでは、データの改ざんや新規の書き込み
- 管理画面やパスワードなど、設定の不正な変更
IPAの資料では、金銭を扱うサイト（ネットバンキング、証券、ショッピング、オークション）や、ログインのあるサイト（管理画面、会員制サイト、日記サイト）が影響を受けやすい例として挙がっています。
XSSとCSRFの違いを比較表で整理する
| 項目 | XSS | CSRF |
|---|---|---|
| 動くもの | 攻撃者が仕込んだスクリプト | 利用者本人の名前で送られる要求 |
| 原因の例 | 入力値などをそのまま画面に出力している | 要求が正規の画面から来たかを確かめていない |
| 被害を受ける人 | そのページを見た利用者 | ログイン中の利用者（や、その利用者のアカウント） |
| 主な被害 | 偽画面の表示、cookie（セッションID）の盗難 | 送金・購入・退会・設定変更・書き込み |
| 根本的な対策 | 画面に出すときのエスケープ | 秘密のトークンの照合、直前のパスワード再入力など |
覚え方は「XSSはスクリプト、CSRFは本人の要求」です。表の一番上の行で区別できます。
2つが組み合わさることもあります。たとえばXSSでスクリプトが動く状態になれば、その中から別の操作を行わせることも考えられます。ただし、試験ではまず「それぞれの定義と対策」を切り分けて覚えるのが基本です。
XSSの対策：出力するときに無害化する
IPAの資料で、根本的な解決として示されているのは出力のエスケープです。エスケープとは、< や >、& のような記号を、スクリプトとして扱われない別の表記に置き換えることです。
IPAの資料から、押さえておきたい点を挙げます。
- HTMLの入力を認めないサイトでは、すべての出力要素をエスケープする（根本的解決）
- 属性値は引用符で囲み、その中の引用符もエスケープする
- URLを出力するときは、
http://やhttps://で始まるものだけを許可する（javascript:で始まるURLを防ぐ） Content-Typeに文字コード（例：UTF-8）を明示する- 入力値の検証は、あくまで補助的な対策として位置づけられている
さらに、保険的な対策として次のものがあります。
- cookieにHttpOnly属性を付け、ページのスクリプトからcookieを読めなくする
- WAF（Web Application Firewall）など、攻撃に当たる通信を検知・遮断する仕組みを使う
HttpOnly属性はcookieの盗難による被害を軽くする補助策で、XSSそのものをなくすものではありません。作りを直すことが本筋です。
CSRFの対策：要求が本人の画面から来たか確かめる
CSRFの対策は、サーバー側が「この要求は本人がこの画面から送ったものか」を確かめられるようにすることです。IPAの資料では、次の方法が示されています。
| 方法 | 内容 | IPAの資料での位置づけ |
|---|---|---|
| 秘密情報（トークン）の埋め込み | 推測されにくい値を画面に埋め込み、要求のときに照合する。処理はPOSTメソッドに限る | 実施を推奨する対策 |
| パスワードの再入力 | 重要な操作の直前に、パスワードを入力させる | 別の確実な対策 |
| Refererの確認 | 要求元のページが正しいか確認する | 回避される場合や、利用者の設定によっては判定できない場合がある |
トークンは、暗号論的に安全な乱数で作ることが前提とされています。攻撃者が罠のページからは値を知りえないので、照合すれば外部からの要求を見分けられます。
補助的な対策として、重要な操作のあとに登録済みのメールアドレスへ通知を送る方法も挙げられています。攻撃を防ぐものではありませんが、利用者が気づく手がかりになります。
試験での問われ方：原因と対策をつなぐ
情報セキュリティマネジメント試験は、科目Aと科目Bの2つで構成され、全60問・120分のCBT方式です（IPAの試験要綱、2026年10月9日確認）。最新の形式は公式サイトで確認してください。
XSSとCSRFは、次のような形で問われると考えておくとよいでしょう。
- 用語の対応を選ぶ：「ログイン中の利用者に意図しない操作をさせる」ならCSRF、「スクリプトが利用者のブラウザで実行される」ならXSS
- 対策を選ぶ：エスケープならXSS、要求ごとのトークンならCSRF
- 事例から原因を考える：入力した文字列が画面に出ていないか、重要な操作の要求が本人のものと確かめられているかをたどる
迷ったら「入力が出力されるときの問題」ならXSS、「要求の出どころを確かめていない問題」ならCSRF、と考えます。
授業・講座で学ぶには
資格のエアポートの情報セキュリティマネジメント講座では、Webアプリケーションへの攻撃と対策を授業で扱っています。ほかの攻撃（SQLインジェクションなど）とあわせて、「どこを直せば止まるか」という視点で整理すると、用語が混ざりにくくなります。AI講師のトーレスに質問しながら、自分の言葉で説明できるか確かめてみてください。
試験の全体像は情報セキュリティマネジメント試験とは、リスクの考え方は脅威・脆弱性・リスクの違いも参考になります。
まとめ
- XSSは、攻撃者のスクリプトが利用者のブラウザで動く攻撃。根本対策は出力時のエスケープ
- CSRFは、ログイン中の利用者の名前で意図しない要求を送らされる攻撃。対策は秘密のトークンの照合やパスワード再入力
- 区別のコツは「何が動くのか」。スクリプトならXSS、本人の要求ならCSRF
「スクリプトが動く＝XSS＝エスケープ」「本人の要求にされる＝CSRF＝トークン」。この対応を押さえれば、用語と対策を結び付ける問題に対応できます。