自社サイトのアクセスログやGoogle Analyticsのレポートを確認した際に、URLの末尾へ見慣れない文字列が付与されているケースに気づくことがあります。
不審なパラメータ付きアクセスが増加している場合、攻撃の事前調査や脆弱性探索が行われている可能性も否定できません。
ニュースやパートナー企業からの情報共有で「クロスサイトスクリプティング（XSS）」という言葉を目にし、不安を感じているWeb担当者も多いでしょう。
本記事では、クロスサイトスクリプティングの仕組みと被害内容に加え、具体的な対策方法まで解説します。
クロスサイトスクリプティング（XSS：Cross-Site Scripting）は、Webアプリケーションの脆弱性を悪用し、利用者のブラウザ上で不正なスクリプトを実行させる攻撃手法です。攻撃者は入力フォームやURLパラメータなどを通じてスクリプトを埋め込み、閲覧者のブラウザ上でJavaScriptなどを動作させます。結果として、利用者のCookie情報や入力情報が外部へ送信される危険があります。クロスサイトスクリプティングは現在も多くのWebサイトで報告されている代表的なWeb脆弱性の一つです。
大規模のWebシステムのみならず、中小企業のコーポレートサイトや問い合わせフォーム、会員機能付きサイトも攻撃対象になり得ます。
独立行政法人情報処理推進機構（IPA）の「ソフトウェア等の脆弱性関連情報に関する届出状況2025年第4四半期」では、累計のWebサイトに関する脆弱性届出のうち57％をクロスサイトスクリプティングが占めています。クロスサイトスクリプティングは例年最も多い脆弱性として報告されています。
※参考：IPA（情報処理推進機構）
ソフトウェア等の脆弱性関連情報に関する届出状況[2025年第4四半期（10月～12月）]
クロスサイトスクリプティングが発生すると、CookieやセッションIDの窃取によるなりすましログイン、個人情報や認証情報の流出、Webページの改ざん、不正なサイトへのリダイレクトといった被害が発生する可能性があります。利用者が正規サイトを閲覧していると認識したまま偽のログイン画面へ誘導されるケースもあり、入力されたIDやパスワードが第三者へ送信される危険があります。
さらに、誘導先でマルウェアに感染したり、認証情報を悪用されて不正送金が行われたりするなど、二次被害に発展する場合もあります。特にログイン機能や会員管理機能を持つWebサイトでは、被害が顧客情報の漏えいに直結しやすく、企業の信用低下や損害賠償リスク、取引停止といった事業上の重大な影響につながる可能性があります。
クロスサイトスクリプティングは、特別な仕組みを狙った高度な攻撃というよりも、Webアプリケーションの基本的な設計や実装の不備によって発生します。利用者からの入力値をどのように受け取り、どのように画面へ出力しているかが重要なポイントです。
まずは、Webアプリケーションの基本的な動作から整理します。
Webアプリケーションは、利用者から送信された入力値をサーバ側で処理し、その結果をHTMLとしてブラウザへ返します。問い合わせフォームや検索機能などでは、入力内容を確認画面や結果画面に再表示する処理が一般的です。
このとき、入力された内容がそのままHTMLとして組み込まれると、ブラウザは文字列ではなく命令として解釈する場合があります。スクリプトが無害化されていなければ、利用者のブラウザ上で実行される可能性があります。
クロスサイトスクリプティングが発生する主な原因は、入力値の検証不足や出力時のエスケープ処理の欠如です。
たとえば、入力フォームに<script>タグが送信された場合でも、適切な検証や変換が行われなければ、そのまま画面に表示されます。ブラウザはHTML内の<script>タグを実行対象として処理するため、不正なJavaScriptが動作します。
入力内容をそのまま受け付ける設計の場合、攻撃者は任意の文字列を送信できます。その中にスクリプトを含めることで、利用者のブラウザ上で任意の処理を実行させることが可能になります。
図の例では、悪意のあるユーザがSNSに【スクリプト1】を埋め込んだ投稿を行い、ボタンのように見せかけています。別のSNS利用者が「今すぐチェック」をクリックすると、あらかじめ用意された偽のページへ遷移します。
銀行に似せた偽ページには【スクリプト2】が含まれており、利用者が入力したIDやパスワードなどの情報が攻撃者へ送信されます。このように、入力値の処理が不適切な場合、正規サイトを経由してフィッシングや情報窃取が実行される可能性があります。
CMSのプラグイン追加や外部サービスとの連携などにより、想定外の入力経路が増えると、すべての処理を網羅的に管理することが難しくなります。その結果、脆弱性が見落とされる可能性があります。
クロスサイトスクリプティングには、主に「反射型」「格納型」「DOMベース型」の3つの発生パターンがあります。
反射型は、URLパラメータなどに埋め込まれたスクリプトが、そのままレスポンス画面に反映されるタイプです。冒頭で記載した「URLの末尾へ見慣れない文字列が付与されている」がこのパターンです。検索結果ページやエラーメッセージ表示画面などで発生しやすく、フィッシングメールと組み合わせて悪用されることがあります。特定のリンクをクリックした利用者のみが被害に遭うケースが多い特徴があります。
格納型は、掲示板やコメント欄、問い合わせフォームなどに入力されたスクリプトがサーバ上に保存され、ページを閲覧した利用者すべてに対して実行されるタイプです。被害範囲が広がりやすく、発見までに時間がかかる場合があります。
DOMベース型は、サーバ側ではなくブラウザ側のJavaScript処理に起因して発生するタイプです。ページ内のスクリプトがURLパラメータなどを安全に処理していない場合に発生します。サーバログに明確な痕跡が残りにくく、検知が難しい場合があります。
クロスサイトスクリプティング対策は、Webアプリケーションの設計・実装段階での対応が基本となります。入力値をどのように受け取り、どのように出力するかを適切に制御することが重要です。
まずは、代表的な実装対策から整理します。
入力値の検証は、想定していないデータを受け付けないための基本対策です。フォームごとに許可する文字種や形式を定義し、条件に合わない入力を排除します。
たとえば、数値のみを受け付ける項目では英字や記号を許可しない、メールアドレス項目では形式チェックを行う、といった方法が挙げられます。不要なHTMLタグやスクリプトを受け付けない設計にすることで、攻撃の成立可能性を下げることができます。
また、入力値の長さに制限を設けることも一定の抑止効果があります。ただし、短いスクリプトでも攻撃は成立するため、長さ制限のみでクロスサイトスクリプティングを防ぐことはできません。文字種制限や出力時のエスケープ処理と組み合わせることが重要です。
出力時のエスケープ処理は、ブラウザがスクリプトとして解釈しないように特殊文字を変換する対策です。
たとえば、「<」や「>」を記号として表示するHTMLの特殊文字へ変換すると、タグとして認識されず文字列として表示されます。さらに、「&」「”」「’」といった文字も適切にエスケープする必要があります。属性値の中に出力される場合、引用符がエスケープ処理されていないとスクリプトが実行される可能性があるためです。
現在のWebフレームワークでは自動エスケープ機能を備えている場合もありますが、設定や実装方法によっては無効化されているケースもあります。出力箇所ごとに適切な処理が行われているか確認することが重要です。
入力値の検証やエスケープ処理を適切に実装していても、すべての経路を完全に管理することは容易ではありません。
CMSのアップデートやプラグイン追加、外部サービスとの連携、開発委託によるコード追加などにより、想定外の入力経路が増えることがあります。また、既存コードの修正漏れや設定ミスによって脆弱性が残る場合もあります。
そのため、クロスサイトスクリプティング対策としては、実装対策に加えて、外部からの不正なリクエストを検知・遮断する仕組みを組み合わせることが重要になります。
入力値の検証や出力時のエスケープ処理は重要な対策ですが、すべての脆弱性を完全に防ぐことは容易ではありません。特に既存サイトやCMSを利用したWebサイトでは、すべてのコードを継続的に確認・改修することが難しい場合があります。
そこで有効となるのが、WAF（Web Application Firewall：ワフ）による防御です。
WAFは、Webサーバの手前で通信内容を監視し、不正なリクエストを検知・遮断する仕組みです。クロスサイトスクリプティング攻撃に特有のスクリプトパターンや不審な入力を検出し、アプリケーションに到達する前にブロックします。
たとえば、リクエスト内に<script>タグや不審なJavaScriptコードが含まれている場合、WAFがその通信を遮断します。攻撃パターンはシグネチャとして管理され、継続的に更新されます。
WAFはアプリケーション改修を伴わずに導入できる点が特徴です。既存のWebサイトに対しても、HTTP/HTTPS（アプリケーション層）通信レベルで防御層を追加できます。
実装対策に加えてWAFを導入することで、万が一アプリケーション側に脆弱性が残っていた場合でも、不正な攻撃通信を遮断できる可能性が高まります。多層防御の観点からも、WAFは有効な対策手段といえます。
WAFについて詳しく知りたい場合はこちら
【WAF入門】Webセキュリティ対策に不可欠のWAFを解説 >
国内シェアNo.1※のクラウド型WAF「攻撃遮断くん」は、クロスサイトスクリプティングを含む各種攻撃から通信レベルで防御できます。攻撃パターンは継続的にアップデートされるため、新たな攻撃手法にも対応可能です。
「攻撃遮断くん」は月額10,000円から導入可能で、既存システムを変更する必要がありません。大がかりな開発やサーバ構成の見直しを行うことなく、最短1日で導入できます。日本国内で開発・運用されているWAFであり、国内環境に適したセキュリティ対策を提供しています。
また、ユーザ側での専門的な運用作業は不要です。シグネチャの更新や監視対応はサービス側で実施されるため、専任のセキュリティ担当者がいない企業でも導入しやすい設計となっています。
クロスサイトスクリプティングによる情報漏えいやなりすまし被害は企業の信用に直結します。実装対策だけに依存せず、通信レベルで防御層を追加することで、低コストかつ効率的にWebセキュリティを強化できます。
アクセスログやURLの末尾に見慣れない文字列が付いている場合、クロスサイトスクリプティングの調査や脆弱性探索が行われている可能性があります。特にWordPressなどのCMSを利用したWebサイトや問い合わせフォームを設置しているサイトでは、知らないうちに脆弱性を突かれているケースも少なくありません。
「自社サイトの対策は十分なのか」「どこから対策すべきなのか」と感じた場合は、一度Webセキュリティ対策の考え方を整理しておくことが重要です。
以下の資料では、クロスサイトスクリプティングを含むWeb攻撃への基本的な対策や、WAFによる防御の仕組みについて分かりやすく解説しています。
まずは以下から詳細をご確認ください。
自社サイトに必要なセキュリティ対策の考え方や導入イメージを確認できます。
デロイト トーマツ ミック経済研究所「外部脅威対策ソリューション市場の現状と将来展望 2024年度」
