クロスサイトスクリプティング（XSS）とは、Webアプリケーションの出力処理の不備を悪用し、Webページに悪意あるスクリプトを埋め込んで、そのページを閲覧した利用者のブラウザ上で実行させる攻撃（およびその脆弱性）です。攻撃の被害を受けるのはWebサーバーそのものではなく「ページを見た利用者」である点が大きな特徴で、Cookieの窃取によるなりすましや偽ページの表示などにつながります。
この記事でわかること
- XSSの定義と、攻撃が成立する仕組み
- 反射型・格納型・DOM型という3つの種類の違い
- 情シスが実務で押さえるべき対策と、開発委託時の注意点
なぜXSSが重要なのか
XSSは「古典的な脆弱性」でありながら、今も日本で最も多く見つかっている脆弱性です。IPAの「安全なウェブサイトの作り方」によれば、届出されたウェブサイトの脆弱性のうち約5割をXSSが占めています。また、脆弱性対策情報データベースJVN iPediaの2026年第1四半期の登録状況でも、CWE別でCWE-79（クロスサイトスクリプティング）が1,163件と最多で、2位のCWE-74（インジェクション、406件）を大きく引き離しています。
つまりXSSは「昔の攻撃」ではなく、自社サイトや導入製品に今この瞬間も存在している可能性が最も高い脆弱性の一つです。実際、JVNで公表される国産ソフトウェアやWebアプリ製品のアドバイザリでも、XSSは定番の項目として登場し続けています。
XSS攻撃はどうやって成立するのか
XSSは、Webアプリケーションが利用者からの入力（検索キーワード、コメント、URLパラメータなど）をページに出力する際、HTMLとして解釈される特殊文字を無害化（エスケープ）せずにそのまま出力してしまうことで成立します。攻撃者は入力欄やURLに <script> タグなどを仕込み、それがページの一部として出力されると、閲覧者のブラウザは「サイトが配信した正規のスクリプト」として実行してしまいます。
「クロスサイト（サイト横断）」という名前は、罠サイトやメール内のリンクを起点に、標的サイト上でスクリプトを実行させるという攻撃の流れに由来します。利用者から見れば「信頼しているサイトを開いただけ」なのに被害に遭うため、利用者側での防御が難しい攻撃です。
XSSの3つの種類
XSSは、スクリプトがどこに存在し、どう実行されるかによって大きく3種類に分けられます。
| 種類 | 仕組み | 特徴 |
|---|---|---|
| 反射型（Reflected） | 攻撃コードを含むURLを踏ませ、リクエストに含まれたスクリプトがそのままレスポンスに「反射」して実行される | 罠リンクをメールやSNSで配布する形が典型。攻撃は1回のアクセスごとに成立 |
| 格納型（Stored／蓄積型） | 掲示板の投稿やプロフィール欄などに攻撃コードを保存させ、そのページを開いた全員のブラウザで実行される | 罠リンク不要で、閲覧者全員が被害対象になるため影響が大きい |
| DOM型（DOM Based） | サーバーを経由せず、ブラウザ上のJavaScriptがURLフラグメント等を不適切に処理することで実行される | サーバー側のログに痕跡が残りにくく、サーバー側の対策だけでは防げない |
XSSで何が起きるのか（想定される被害）
IPAは、XSSにより発生しうる脅威として次のようなものを挙げています。
- Cookie（セッションID）の窃取：ログイン状態を乗っ取られ、利用者になりすまされる
- 偽ページの表示：正規サイトのURLのまま偽の入力フォーム等を表示され、フィッシングに悪用される
- 意図しないCookieの保存：セッション固定化攻撃（セッションIDの強制）に悪用される
「正規のURL・正規のサーバー証明書のまま」被害が起きるため、利用者に「URLをよく確認しましょう」と啓発しても防げないのがXSSの厄介なところです。防ぐ責任はサイト運営側にあります。
情シスの実務でどう扱うか
自社サイト・自社開発アプリがある場合
- 根本対策は「出力時のエスケープ処理」です。開発標準・コーディング規約にエスケープ処理の徹底を明記し、開発委託時は要件・検収条件に含めます。IPA「安全なウェブサイトの作り方」を委託先との共通言語にするのが現実的です。
- リリース前・定期の脆弱性診断でXSSは必ず検査対象に含めます。届出の約5割を占める＝診断すれば見つかる可能性が高い脆弱性です。
- 緩和策として、CookieのHttpOnly属性（スクリプトからのCookie参照を禁止）やContent Security Policy（CSP）の導入も有効ですが、これらはあくまで被害軽減であり、エスケープ処理の代わりにはなりません。
パッケージ製品・SaaSを使っている場合
- JVN等で自社利用製品のXSS脆弱性が公表されたら、修正版の適用が基本対応です。管理画面がXSSの標的になるケースも多いため、「社内システムだから後回し」にしないことが重要です。
- WAFによる防御は「修正までの時間稼ぎ」として位置づけ、恒久対策（パッチ適用・改修）とセットで計画します。
現場目線の所感
XSSは対策方法が確立して20年以上経つのに、いまだに届出の半分を占め続けています。現場の実感としては、新規開発では対策されていても、古い社内システムや、担当者が退職して誰も触れないWebアプリに残り続けるケースが多いように思います。「動いているから触らない」レガシーWebアプリの棚卸しは腰が重い仕事ですが、XSSのような定番脆弱性の温床になりがちです。全部を一度に改修するのは無理でも、せめて「どこに何のWebアプリがあるか」の台帳を持っておくだけで、脆弱性公表時の初動がまったく変わります。
対策の詳細は公的指針へ
XSSの具体的な対策（エスケープ処理の実装方法、根本的解決と保険的対策の切り分け）は、IPAの「安全なウェブサイトの作り方 – 1.5 クロスサイト・スクリプティング」が定番かつ無料の一次情報です。開発者に読んでもらう資料としても、委託先への要求水準を示す資料としても使えます。
関連用語
- SQLインジェクションとは？仕組みと情シスの対策を解説 … 同じ「入力値の不適切な処理」に起因する定番脆弱性。XSSが利用者を狙うのに対し、こちらはデータベースを直接狙います
- WAFとは？仕組み・種類と導入時の注意点を解説 … XSS・SQLインジェクション等のWeb攻撃を検知・遮断する「時間稼ぎの盾」
- IDS／IPSとは？仕組み・種類と運用の注意点を解説 … ネットワーク層での不正検知・防御の基本
まとめ
- XSSはWebページに悪意あるスクリプトを埋め込み、閲覧者のブラウザ上で実行させる攻撃。被害者はサーバーではなく利用者で、Cookie窃取や偽ページ表示につながる
- 届出されたウェブサイト脆弱性の約5割を占め、JVN iPediaの2026年Q1登録でもCWE-79が最多（1,163件）。「古いが現役」の脆弱性の代表格
- 根本対策は出力時のエスケープ処理。情シスは開発規約・委託要件・脆弱性診断に組み込み、WAFやCSPは緩和策として併用する
