サイバー攻撃の手口が多様化する中で、依然として根強い脅威となっているのが「クロスサイトスクリプティング（XSS）」です。
XSSは古くから知られる代表的な脆弱性のひとつであり、開発者の油断や対策の甘さを突いて、今なお多くのウェブサイトが標的となっています。
本記事では、XSSの仕組みや攻撃の具体例、そして開発者・利用者が講じるべき対策方法について、図解や事例を交えてわかりやすく解説します。
クロスサイトスクリプティング（XSS）とは？
クロスサイトスクリプティング（Cross-Site Scripting、XSS）は、ウェブアプリケーションの脆弱性を悪用し、ユーザーのブラウザ上で不正なスクリプトを実行させるサイバー攻撃です。攻撃が成功すると、情報漏えいやウェブサイトの改ざんといった深刻な被害を引き起こすおそれがあります。ここでは、XSSの基本的な仕組みと、攻撃が成立するプロセスを整理します。
なぜ「XSS」と略すのか
「XSS」という略称は、頭文字をそのまま取ると「CSS」になりそうですが、これはすでにスタイルシート言語（Cascading Style Sheets）で使用されているため、混同を避ける目的で「XSS」が使われています。X = Cross（頭文字ではなく、「交差する」の意味から）
S = Site
S = Scripting
この略称はセキュリティ業界で長年使われており、現在も世界的に定着しています。
攻撃の流れと仕組み
クロスサイトスクリプティング（XSS）は、以下のような流れで攻撃が成立します。
1. スクリプトの混入
攻撃者が、ウェブサイトの入力フォームやURLパラメータなどに悪意のあるスクリプトを埋め込みます。
2.ユーザーがアクセス
ユーザーが、スクリプトが仕込まれたページやリンクにアクセスします。
このとき、ウェブサーバーはユーザーのリクエスト（リンクのクリックやフォームの入力など）に応じてページを生成し、ブラウザに返します。
もしこのレスポンスに、攻撃者が埋め込んだスクリプトが含まれていれば、そのままブラウザに表示されることになります。
3. スクリプトの送信
サーバーが、入力内容をそのままHTMLに反映させる仕様になっている場合、スクリプトも一緒に送信されてしまいます。
本来であれば、入力内容に不正なコードが含まれていないかを検証（バリデーション）し、表示時には無害化（エスケープ）する必要があります。これらの処理が不足していると、攻撃が成立してしまいます。
4. スクリプトの実行
ユーザーのブラウザが、スクリプトを正規のコンテンツとみなして処理・実行してしまいます。
このように、入力値の検証や出力時のエスケープ処理が不十分なウェブサイトでは、XSS攻撃が容易に成立します。
結果として、ユーザーのセッション情報（Cookieなど）が盗まれたり、不正な操作や表示が行われたりするリスクがあります。
よくある入力フォームの例と攻撃手法
XSS攻撃は、ユーザーが入力した内容が画面にそのまま表示される仕組みを悪用します。とくに、以下のような入力フォームは攻撃の対象になりやすいため、設計や実装の段階で十分な対策を講じる必要があります。・お問い合わせフォームやコメント欄
・検索ボックスやURLパラメータ
・会員登録・ログイン画面などの入力ページ
これらのフォームに対して、攻撃者が悪意あるスクリプトを入力し、サイト側で適切な処理が行われていない場合、そのスクリプトが他のユーザーのブラウザ上で実行されるおそれがあります。
CSRFとの違い：XSSと混同しやすい2つの攻撃
XSS（クロスサイトスクリプティング）とCSRF（クロスサイトリクエストフォージェリ）は、いずれもWebブラウザを介してユーザーに被害を与える攻撃手法として知られています。
どちらも「ユーザーの意図しない動作を引き起こす」という点で共通しますが、目的と攻撃の仕組みはまったく異なります。下記にその違いを簡単にまとめます。
| 比較項目 | CSRF | XSS |
|---|---|---|
| 攻撃の目的 | ユーザーの権限を借りた操作の実行 | ユーザーのブラウザでのスクリプト実行 |
| 攻撃の対象 | 認証済みユーザーのセッション | ユーザーのブラウザ環境 |
| 主な被害 | 意図しない操作の実行 | Cookie盗難、フィッシング、マルウェア感染など |
CSRF（クロスサイトリクエストフォージェリ）についての詳細は、こちらの記事で解説しています。
▼CSRFとは？仕組み・被害事例・対策までやさしく解説【図解つき】
本記事では、このうち「XSS」に焦点を当て、仕組み・被害・対策方法を順に解説していきます。
クロスサイトスクリプティング（XSS）の主な種類と特徴
クロスサイトスクリプティング（XSS）攻撃は、その手法や影響範囲に応じていくつかの種類に分類されます。代表的なタイプには「反射型」「格納型」「DOM Based」の3つがあり、それぞれ対策のポイントも異なります。
以下では、それぞれのタイプについて、発生原因と想定される被害をわかりやすく整理します。
反射型XSS（Reflected XSS）
発生原因：
主にURLパラメータや検索キーワードなど、ユーザーが入力した情報がサーバー経由でそのままレスポンスに反映される場合に発生します。例えば、検索機能で入力内容が画面にそのまま表示されるサイトがこれに該当します。
想定される被害：
攻撃者が細工したURLをユーザーにクリックさせることで、その場で悪意あるスクリプトが実行され、セッション情報の窃取や偽のログインフォームによる情報搾取が起こります。スクリプトは一時的で、対象はURLを開いたユーザーに限られます。
格納型XSS（Stored XSS）
発生原因：
掲示板やコメント欄などの入力内容が、サーバー側のデータベースに保存され、後に他ユーザーへ表示される場合に発生します。保存されたスクリプトが、複数のユーザーの画面で実行されることで問題が拡大します。
想定される被害：
スクリプトが永続的に保存されるため、複数ユーザーがマルウェア感染やフィッシング被害に遭うリスクが高く、企業サイトの改ざんによる信用失墜にもつながります。 特に影響範囲が広く、深刻度が高いのが特徴です。
DOM Based XSS
発生原因：
クライアントサイド（JavaScript）でDOMを操作する処理がある場合、URLの一部やブラウザ上のデータを元に画面が動的に変化する設計になっていると発生します。サーバーを経由しないため、ログなどで検出されにくいのも特徴です。
想定される被害：
ユーザーのブラウザ上でスクリプトが実行され、個人情報の窃取やフィッシングフォームの表示などが発生します。見た目は通常のサイトと変わらないため、被害者が気づきにくく、対応が遅れる傾向にあります。
XSSタイプ別の比較表
| 種類 | スクリプトの保存場所 | 主な攻撃経路 | 影響範囲 |
|---|---|---|---|
| 反射型XSS | 保存されない（一時的） | 悪意のあるURLのクリック | 限定的（標的型） |
| 格納型XSS | ウェブサイトのDB等に保存 | 脆弱なページの閲覧 | 広範囲（不特定多数） |
| DOM Based XSS | ブラウザのDOM内（一時的） | URLの一部や動的なJS操作 | 可変（検知しにくい） |
クロスサイトスクリプティングが引き起こす被害とは
XSS攻撃によって、ユーザーやサイト運営者はさまざまな被害を受ける可能性があります。以下に代表的な被害例を紹介します。セッション情報の盗難とアカウント乗っ取り
XSSを利用すると、ユーザーのブラウザに保存されているCookie（セッションIDなど）を盗み取ることが可能です。盗まれたCookie情報を悪用されると、攻撃者は正規のユーザーになりすまし、アカウントへ不正にアクセスまたは乗っ取ることができます（通称：セッションハイジャック）。
その結果、機密情報が閲覧されたり、不正な操作が行われたりするおそれがあります。
偽のログイン画面による情報搾取（フィッシング）
XSSは、本物のサイト上に偽のログインフォームを表示させ、ユーザーの認証情報を入力させて盗み取ることが可能です。いわゆるフィッシングです。ユーザーが正規のサイトと誤認して認証情報やクレジットカード情報などを入力してしまうと、それらの情報が攻撃者に送信され、フィッシング詐欺の被害に遭うことになります。
本物のサイト上に偽フォームが表示されるため、ユーザーは気づかず入力してしまうことがあります。
【内部リンク】横行するフィッシング詐欺。なりすまし偽サイトを防ぐ企業の対策方法とは？ | サイバー保険ガイド
ウェブサイトの見た目や内容の改ざん
スクリプトを用いてサイトの表示内容を書き換えることで、虚偽の情報を掲載したり、不適切なコンテンツを表示させたりできます。たとえば、企業サイトに虚偽の情報を表示したり、不適切な画像を掲載することで、企業の信用を著しく損なう可能性があります。
また、マルウェアを配布する外部サイトへユーザーを自動的に転送（リダイレクト）するような改ざんも行われることがあります。
マルウェア感染・踏み台化のリスク
悪意あるスクリプトを介して、ユーザーのPCにさらに別のマルウェアをダウンロードさせることもあります。これにより、ユーザーの端末がマルウェアに感染し、さらなる情報漏洩や不正操作の被害につながるおそれがあります。
知らないうちに、自身のコンピュータがサイバー攻撃の踏み台にされてしまうケースもあります。
なぜクロスサイトスクリプティング（XSS）が発生するのか
XSSは、ウェブアプリケーションの設計や実装における不備によって発生します。とくに、入力値を適切に処理せずに画面に表示したり、古いライブラリを使用していると、意図せずスクリプトが実行されてしまうことがあります。ここでは、XSSの代表的な原因を解説します。
入力値の検証が不十分
フォームやURLパラメータから受け取った入力を無条件で受け入れてしまうと、悪意あるスクリプトが混入します。たとえば、HTMLタグを許可していないコメント欄にスクリプトを埋め込まれ、それがそのまま保存・表示されると、ブラウザで実行される可能性があります。
想定外の形式や文字列をブロックする「ホワイトリスト方式」の導入が重要です。
出力時のエスケープ処理が不足している
HTMLに出力する際に、< や >、& などの記号を無害化せずそのまま表示すると、スクリプトとして解釈されることがあります。たとえば、<script>alert(‘XSS’)</script> のような入力が無処理のままページに反映されると、スクリプトが実行されるリスクがあります。
ユーザーの入力を出力する箇所では、HTMLやJavaScriptの文脈に応じた適切なエスケープ処理が欠かせません。
古いライブラリやフレームワークを使用している
過去に脆弱性が見つかっているバージョンのフレームワークを使い続けていると、XSSの標的になるリスクがあります。ベンダーが提供するセキュリティパッチやアップデートを適用していない状態では、既知の脆弱性が悪用されやすくなります。
>開発元から提供される更新情報を常に確認し、定期的なアップデートを欠かさないことが大切です。
クロスサイトスクリプティング（XSS）への具体的な対策
クロスサイトスクリプティング（XSS）の脅威からウェブサイトを守るには、多層的な対策が必要です。ここでは、XSSへの基本対策と、関係者ごとの具体策を解説します。
基本となる4つの技術的対策
XSS対策の基本は、「入力値の検証（バリデーション）」と「出力時のエスケープ処理」の徹底です。これは「入り口対策」と「出口対策」とも呼ばれ、両方を実施することでセキュリティレベルを大きく高めることができます。
- 入力値の検証（バリデーション）
フォームやURLパラメータなどの入力値を、受け付ける文字種・形式・長さで制限します。特に、許可された形式だけを明示する「ホワイトリスト方式」が効果的です。 - 出力時のエスケープ処理
ユーザー入力をHTMLなどに出力する際、< や >、& などの記号を実体参照に変換し、スクリプトとして解釈されないようにします。HTML、JavaScript、URLなど出力先に応じた方法を選ぶ必要があります。
IPAでは「安全なウェブサイトの作り方」の中で、具体的なエスケープ処理の方法を解説しています。
参照：IPA「安全なウェブサイトの作り方 – 1.6 CSRF（クロスサイト・リクエスト・フォージェリ）」 - セキュリティヘッダーの活用
HTTPレスポンスに Content-Security-Policy（CSP） などを設定し、信頼されたドメイン以外からのスクリプト実行を防ぎます。たとえ悪意のあるスクリプトが挿入されても、ブラウザ側での実行を抑止できます。 - ライブラリやフレームワークの安全性維持
古いバージョンのフレームワークやライブラリには、既知の脆弱性が残っている可能性があります。定期的にアップデートやセキュリティパッチを適用することで、リスクを最小限に抑えられます。
開発者が講じるべき対策
- 入力値のサニタイズ：JavaScriptやHTMLタグなどの不要なコードを除去します。
- 信頼できるライブラリの使用：保守されている安全なライブラリを活用します。
- テスト・コードレビューの徹底：脆弱性の検出を目的としたセキュリティテストやコードレビューを継続的に実施します。
- 安全なコーディング手法の採用
セキュアコーディングを開発初期から取り入れましょう。特に、近年のフレームワーク（React、Vue、Djangoなど）にはXSS対策機能（自動エスケープ等）が標準搭載されており、これらを正しく利用することが大切です。チーム内の教育や知識共有も重要です。
運用者が実施すべき対策
- WAF（Web Application Firewall）の導入
既知の攻撃パターンを検知・遮断するWAFを導入することで、アプリケーションの脆弱性を狙った攻撃をブロックできます。即時修正が難しい場合の緊急対応にも有効です。 - 脆弱性情報の定期チェックと更新
使用中のCMSやフレームワークの脆弱性情報を定期的に確認し、必要なアップデートを適用することが求められます。
▼WAFとは？仕組み・種類・メリット・選び方をわかりやすく解説【企業向けセキュリティ対策】
利用者側で意識すべき対策
- 不審なリンクは開かないようにする
- 信頼できないサイトに個人情報を入力しない
- ブラウザやOS、セキュリティソフトを最新の状態に保つ
- パスワードの使い回しを避け、二要素認証を有効にする
XSSは、1つの対策だけで防ぎきるのが難しい攻撃手法です。開発者・運用者・利用者のすべてが、それぞれの立場で役割を果たすことが、被害の未然防止につながります。
クロスサイトスクリプティング（XSS）脆弱性の診断方法
自社のウェブサイトにクロスサイトスクリプティング脆弱性が存在しないかを確認するためには、定期的な脆弱性診断が不可欠です。診断方法には、手動で行うものからツールを利用するもの、専門家へ依頼する方法まで様々です。それぞれの特徴を理解し、状況に応じて適切な方法を選択しましょう。
手動による脆弱性診断の進め方
手動による脆弱性診断では、実際にウェブサイトの入力フォームやURLパラメータにテスト用の簡単なスクリプト（例：<script>alert(‘XSS’)</script>）を入力し、それが実行されるかどうかを確認します。また、ブラウザの開発者ツールを活用して、DOM構造やJavaScriptの挙動を詳細に分析することもあります。
この方法は、自動ツールでは検出が難しい複雑な脆弱性や、アプリケーション固有のロジックに起因する問題の発見に有効です。ただし、診断結果は診断者のスキルや経験に大きく左右され、網羅的な診断には時間と手間がかかるという側面もあります。
セキュリティ診断ツールの活用
XSS脆弱性のスキャンが可能なセキュリティ診断ツールも多数公開されています。URLを指定するだけで、既知の攻撃パターンを試行し、脆弱性の有無をレポートするものが一般的です。オープンソースのものから商用の高機能ツールまで幅広く、手軽に広範囲をチェックできる点がメリットです。
ただし、ツールには誤検知（脆弱性がないのに検出される）や検知漏れ（存在するのに見逃す）といったリスクもあります。結果を過信せず、必要に応じて手動での検証を組み合わせることが望ましいでしょう。
専門家による脆弱性診断サービスの利用
より高精度かつ信頼性の高い診断を求める場合には、セキュリティ専門企業による診断サービスの活用を検討しましょう。専門のエンジニアが、手動診断とツール診断を組み合わせて、アプリケーションの特性に応じた詳細な検査を実施します。
具体的な対策のアドバイスも受けられるため、自社内での対応が難しい場合にも有効です。 費用は発生しますが、見逃されやすい脆弱性の発見や、確実なセキュリティ強化につながります。
サービスを選ぶ際は、診断実績や担当者のスキル、報告書の分かりやすさなどを複数社で比較検討することをおすすめします。
まとめ：クロスサイトスクリプティング（XSS）対策と共に、サイバー保険を
技術的なクロスサイトスクリプティング（XSS）対策を講じることは非常に重要ですが、万が一の被害発生に備える視点も欠かせません。事故発生後の損害賠償や対応費用に備え、サイバー保険の一括見積で、補償内容を比較・検討しておくことをおすすめします。
特にWebサービス等を提供している企業は、インシデントが起こった際のリスク分散が重要となります。
また、保険会社が用意している脆弱性診断サービスも利用が可能です。
（保険会社のプラン・サービスにより異なります。詳しくはお問合せください。）
▶ サイバー保険 一括見積はこちら（無料）
当サイトを運営する「ファーストプレイス」では、
大手5社のサイバー保険の保険料を、無料で一括比較・見積りいただけます。
- 東京海上日動火災保険株式会社
- 三井住友海上火災保険株式会社
- 損害保険ジャパン株式会社
- あいおいニッセイ同和損害保険株式会社
- AIG損害保険株式会社
ECサイトやWebサービスを提供している企業様は、IT業務を提供する企業様向けの「IT業務用サイバー保険一括見積サイト」もご検討ください。
クロスサイトスクリプティングに関するよくある質問（FAQ）
Q1. XSSとCSRFはどう違うのですか？A. XSSは「ユーザーのブラウザ上でスクリプトを不正に実行させる攻撃」、CSRFは「ユーザーが意図しないリクエストを送信させる攻撃」です。どちらも被害者の行動を利用しますが、XSSは“画面の改ざん、CSRFは操作の強制が主な目的です。
Q2. 反射型・格納型・DOM型とは何が違いますか？
A. 反射型：ユーザーが入力した内容がすぐにレスポンスに反映され実行される
格納型：スクリプトがサーバー上に保存され、複数のユーザーに影響を与える
DOM型：サーバーを介さず、JavaScriptでDOMを操作して実行される
Q3. WAF（Web Application Firewall）はXSSに有効ですか？
A. 一定の効果はありますが、WAFだけでは完全に防げません。安全な開発と複数の防御策を組み合わせることが重要です。
Q4. 普段の利用者として気をつけるべきことは？
A. 不審なリンクをクリックしない、信頼できないサイトでログインや個人情報の入力を控えるなど、基本的なネットリテラシーを持つことがXSS被害の防止につながります。
参照：IPA「安全なウェブサイトの作り方」
参照：OWASP Foundation「Cross Site Scripting (XSS)」
