XSSは、フォームに入れた文字が、別の人の画面でスクリプトとして動いてしまう脆弱性です。仕組みと、確実な防ぎ方をゼロから解説します（攻撃手順は載せません）。
3つの型
XSSは「悪意ある文字列がどこを通って実行されるか」で3つに分かれます。
| 型 | どう仕込まれるか |
|---|---|
| 蓄積型（Stored） | 投稿やプロフィール等に保存され、閲覧した全員のブラウザで実行される（最も危険） |
| 反射型（Reflected） | URLパラメータ等がそのまま画面に反射され、リンクを踏んだ人で実行される |
| DOM型（DOM-based） | サーバーを介さず、ブラウザ側のJSが入力を危険に扱うことで発生 |
なぜ危険か（仕組み）
ブラウザは、ページに書かれた <script> を「正規のコード」として実行します。攻撃者の文字列がそのままHTMLとしてページに混ざると、ブラウザはそれを本物のコードと区別できません。
被害は「そのページでできること」全部です。RCE がサーバー側で最も深刻な脆弱性なら、XSSはクライアント側（利用者）で最も深刻な脆弱性にあたります。
防御：出力時にエスケープする
XSSは“入力”でなく“出力”で防ぐのが基本です。値を画面に出す瞬間に、HTMLとして解釈されない形へ変換します。
出力時にエスケープする（最重要）
ユーザー由来の値を画面に出すとき、< > & " ' などをHTMLエンティティに変換。出す場所（HTML本文・属性・JS・URL）ごとに正しい方式で。
フレームワークの自動エスケープを外さない
React/Vue/各テンプレートは既定で自動エスケープします。dangerouslySetInnerHTML や v-html のような“生HTML挿入”を避けるだけで大半を防げます。
CSP（Content-Security-Policy）で多層防御
万一漏れても、許可していないスクリプトの実行をブラウザ側で止める。インラインスクリプトの制限などで被害を抑える。
Cookieを守る
セッションCookieに HttpOnly を付け、JSから読めなくする。盗まれても被害を限定。
当サイトの視点：最大の防御は、自分で安全機能を外さないこと
モダンなフレームワークは既定で安全な設定になっています。XSSの多くは、開発者が 「HTMLをそのまま入れたい」と自動エスケープを意図的に外した瞬間に生まれます。どうしてもHTMLを許可するなら、自前の文字列処理ではなく実績あるサニタイザを通すこと。「便利のために安全を外す」のが最大のリスクです。
よく混同される攻撃との違い
XSSは、名前の似たCSRFや、同じ「入力が命令として扱われる」型のSQLインジェクションと混同されがちです。違いは、何がどこで動くかです。
| 攻撃 | どこで何が起きるか | 主な防御 |
|---|---|---|
| XSS | 攻撃者のスクリプトが、利用者のブラウザで本物のページの一部として動く | 出力時のエスケープ・CSP |
| CSRF | 利用者のログイン状態を使い、本人が意図しないリクエストを送らせる。スクリプトの実行は不要 | CSRFトークン・SameSite Cookie |
| SQLインジェクション | 入力がサーバー側でSQLの一部として解釈される | プレースホルダ |
| クリックジャッキング | 透明に重ねた本物のページを、利用者に気づかれずにクリックさせる | CSPの frame-ancestors |
注意したいのは、XSSがあるとCSRF対策も効かなくなる点です。ページの中でスクリプトが動けば、そのページにあるCSRFトークンも読めてしまうからです（OWASPのCSRF対策ガイドも同じ注意を書いています）。
具体例：社内の担当者が開く画面で動いたXSS
2026年、学習管理システムCanvasの運営会社Instructureは、不正アクセスの経路がXSSだったと公表しました。同社によれば、攻撃者は無料版のアカウントから悪意のあるコードを含むサポート依頼を送り、サポート担当者がそれを開いたときにXSSが悪用され、Canvasの中で高い権限を得たとしています（→ Canvas（Instructure）の情報漏えい）。
この事例から分かるのは、XSSは利用者向けの公開ページだけの問題ではないということです。問い合わせ・サポート・管理画面のように、外から届いた文字列を社内の担当者が表示する画面は、権限の強いアカウントが開くぶん、被害が大きくなります。
XSSは今も最も多く見つかる弱点の一つです。MITREが2025年12月に公表した「CWE Top 25」（危険なソフトウェアの弱点の上位25）では、XSS（CWE-79）が1位でした。米国のCISAとFBIも2024年9月、ソフトウェアを作る企業に向けて、XSSを製品からなくすよう求める注意喚起を出しています。
自分のサイトで確認する方法
攻撃用の文字列を試す必要はありません。まず次の4点を確認します。
生のHTMLを入れている箇所を探す
ソースコードを dangerouslySetInnerHTML・v-html・innerHTML・document.write で検索し、そこに利用者由来の値が入る経路がないかを確かめる。入るなら、テキストとして出す形に変えるか、実績あるサニタイザを通す。
CSPが出ているかを見る
セキュリティヘッダ診断で Content-Security-Policy の有無と中身を確認する。'unsafe-inline' を許可していると、XSSへの効果は大きく下がる。新しく作るならCSPビルダーで下書きし、まず Report-Only（違反を報告するだけのモード）で様子を見る。
セッションCookieの属性を見る
ブラウザの開発者ツール（Application → Cookies）で、セッションCookieに HttpOnly と Secure が付いているかを確認する。サイト総合セキュリティ診断でもCookie属性を点検できる。
管理画面とサポート画面も対象に含める
問い合わせ本文・ファイル名・表示名など、外から届いた文字列を表示する社内向けの画面も、公開ページと同じ基準でエスケープされているかを確認する。
出典（一次情報）
- OWASP「Cross Site Scripting Prevention Cheat Sheet」 — cheatsheetseries.owasp.org（出力する文脈ごとのエスケープ、フレームワークの安全な既定）
- MITRE「2025 CWE Top 25 Most Dangerous Software Weaknesses」（2025年12月） — cwe.mitre.org（CWE-79 が1位）
- CISA・FBI「Secure by Design Alert: Eliminating Cross-Site Scripting Vulnerabilities」（2024年9月17日） — cisa.gov
- OWASP「Cross-Site Request Forgery Prevention Cheat Sheet」 — cheatsheetseries.owasp.org（XSSがあるとCSRF対策が回避される）
- IPA「安全なウェブサイトの作り方」 — ipa.go.jp
次に読む
- 用語：CSRF とは / RCE とは / JWT とは（XSSで盗まれやすいトークン）
- 多層防御：セキュリティヘッダは並べるものではない（CSPでXSSの被害幅を狭める）
- 入門：セキュリティ超入門
分類番号
CWE は脆弱性の原因となる弱点の種類を、MITRE ATT&CK は攻撃者の手口を分類した番号体系です。どちらも MITRE が管理し、脆弱性情報や検知ルールの分類に広く使われています。
CWE（弱点の種類）
CWE™: Copyright © 2006–2026, The MITRE Corporation. CWE is a trademark of The MITRE Corporation. The MITRE Corporation hereby grants you a non-exclusive, royalty-free license to use CWE for research, development, and commercial purposes. Any copy you make for such purposes is authorized on the condition that you reproduce MITRE’s copyright designation and this license in any such copy. CWE Terms of Use
よくある質問
QXSSで何が起きる？
攻撃者が仕込んだスクリプトが、被害者のブラウザで本物のページの一部として実行されます。結果としてセッションの窃取（なりすましログイン）、入力の盗み見、画面の改ざん、別の操作の自動実行などが起こり得ます。
QXSSの一番の防御は？
『出力時のエスケープ』です。ユーザー由来の値を画面に出すとき、HTMLとして解釈されないように変換します。React/Vue等のテンプレートは既定でこれを行うので、その自動エスケープを自分で外さない（dangerouslySetInnerHTML等を避ける）ことが最大の対策です。加えてCSPで多層防御します。
Q入力時にサニタイズすれば十分？
不十分になりがちです。基本は『出力する文脈（HTML本文・属性・JS・URL）ごとに正しくエスケープする』こと。入力フィルタだけだと文脈の取り違えで漏れます。HTMLを許可したい場合だけ、信頼できるサニタイザを使います。
Qなぜ略称がCSSではなくXSSなの？
Cross-Site Scripting の頭文字はCSSですが、Webページの見た目を指定するCSS（Cascading Style Sheets）と紛らわしいため、Cross を X で表して XSS と書くのが一般的です。読み方は「エックスエスエス」、日本語では「クロスサイトスクリプティング」です。
QCSPを入れればXSS対策は不要？
不要にはなりません。CSP（Content-Security-Policy）は、エスケープが漏れたときに被害を抑える2段目の対策です。特に 'unsafe-inline' を許可したCSPは、XSSへの効果が大きく下がります。基本は出力時のエスケープで、CSPはその上に重ねます。
QCookieに HttpOnly を付ければXSSは怖くない？
被害は減りますが、なくなりません。HttpOnly はスクリプトからCookieを読めなくするだけです。XSSで動いたスクリプトは、そのページの中で本人として操作を送ったり、画面に表示された情報を読んだりできます。HttpOnly は被害を小さくする対策で、XSS自体を防ぐものではありません。