【IPAデータ】クロスサイトスクリプティング（XSS）とは｜仕組みと届出状況・対策、ウェブサイト脆弱性の累計56%を占める（2026年）

クロスサイトスクリプティング（XSS）は、セキュリティの話題でよく出てくる言葉ですよね。ただ、自社のWebサイトに関係する話として考えると、分からないことも多いのではないでしょうか。

• XSSという言葉は聞くけれど、SQLインジェクションとの違いを説明できない
• 自社の問い合わせフォームや会員ページは大丈夫なのか気になる
• 開発会社に何を確認すればいいのか分からない

先に結論をお伝えします。XSSは、Webページに攻撃者のスクリプトを紛れ込ませ、閲覧者のブラウザで動かす攻撃です。

IPAの届出統計では、2004年の制度開始からの累計で、ウェブサイトの脆弱性の56%を占めています（2026年第2四半期末時点）。種類別で最も多い脆弱性です。

この記事では、XSSの仕組みと3つの種類を、コードを書かない情シスの方にも分かるように整理します。そのうえで、IPAの届出統計で見たXSSの位置づけと読み方の注意点、情シスが確認するべき対策の観点を解説します。

この記事のポイント

• IPAの届出統計では、XSSはウェブサイト脆弱性の累計の56%を占め、SQLインジェクション（11%）の約5倍です（2026年6月末時点、出典: IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2026年第2四半期（4月〜6月）］」PDF版）
• ただし56%は2004年からの累計の値です。2026年4〜6月の新規届出65件に限ると、XSSは8件で約12%でした
• 根本の対策は、開発時に出力内容をエスケープすることです。情シスは仕様書と受入れ確認で、この対策が入っているかを確かめます

クロスサイトスクリプティングはWebページにスクリプトを紛れ込ませ、閲覧者のブラウザで実行させる攻撃

クロスサイトスクリプティング（XSS）とは、Webページに攻撃者のスクリプトを紛れ込ませ、そのページを見た人のブラウザで実行させる攻撃です。狙われるのはサーバーそのものではなく、サイトを閲覧している利用者です。

攻撃は、大まかに3つの段階で進みます。まず、攻撃者が入力欄やURLにスクリプトを含む値を入れます。

次に、Webアプリがその値を無害化しないまま、HTMLの一部として画面に出力します。最後に、閲覧者のブラウザがそのスクリプトを正規のページの一部として実行してしまいます。

つまり、原因は「入力された値を、そのまま画面に表示してしまう作り」にあります。ここからは、気づきにくい理由と被害の内容、ほかの攻撃との違いを順に見ていきましょう。

スクリプトはサイト自身から配信されるため、閲覧者は攻撃に気づきにくい

XSSが厄介なのは、攻撃者のスクリプトが、本物のサイトのドメインから配信される点です。閲覧者から見ると、いつも使っている正規のサイトを開いているだけなので、異変に気づくのは難しくなります。

ブラウザも、同じページに含まれるスクリプトが正規のものか、紛れ込んだものかを区別できません。そのため、紛れ込んだスクリプトは、そのサイトのスクリプトと同じ権限で動いてしまいます。

名前の「クロスサイト」は、攻撃者が用意した罠のサイトから、標的のサイトへと「サイトをまたいで」攻撃が行われることに由来するとされます。ただし、後で説明する格納型のように、罠のサイトを経由しないXSSもあります。略称が「CSS」ではなく「XSS」なのは、Webページの見た目を指定するスタイルシートのCSSと区別するためです。

被害はCookieの盗用によるなりすまし、偽の情報や入力フォームの表示、別サイトへの誘導が中心

XSSで起きる被害は、主に次の3つです。いずれも、正規のサイト上でスクリプトが動くことを利用したものです。

• セッションCookieが盗まれ、ログイン中の利用者になりすまされる
• 本物のページに、偽の情報や偽のログインフォームが表示される
• 利用者がフィッシングサイトなどの別のサイトへ誘導される

IPAも、本物のサイト上に偽の情報が表示される被害の主な原因の一つとして、XSSを挙げています。

ここで押さえておきたいのは、被害の構図です。直接被害を受けるのはサイトの利用者で、サイトの運営者は利用者からの信用を失うという形になります。自社サイトの問題がそのまま顧客の被害につながる点は、意識しておきたいところですね。

SQLインジェクションはサーバー側のデータベースを狙い、XSSは利用者のブラウザを狙う

XSSは、SQLインジェクションと並んで「Web攻撃の二大手口」としてよく取り上げられます。どちらも入力値の扱いの不備を突く攻撃ですが、攻撃される場所が違います。 あわせて、名前が似ているCSRF（クロスサイトリクエストフォージェリ）とも比べてみましょう。

攻撃	攻撃される場所	主な被害	基本の対策
SQLインジェクション	サーバー側のデータベース	情報の盗み出し、データの改ざん・消去	プレースホルダを使ってSQL文を組み立てる
クロスサイトスクリプティング（XSS）	閲覧者のブラウザ	なりすまし、偽情報の表示、別サイトへの誘導	画面に出力する値をエスケープする
CSRF	ログイン中の利用者の操作	利用者が意図しない投稿・設定変更・購入など	正規の画面からの操作かを確認する仕組みを入れる

CSRFは、利用者に意図しない操作をさせる攻撃で、スクリプトを紛れ込ませるXSSとは仕組みが異なります。名前が似ていても別の攻撃なので、対策も分けて考える必要があります。

出典: IPA「安全なウェブサイトの作り方」／IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2026年第2四半期（4月〜6月）］」PDF版

XSSは主に反射型・格納型・DOM型の3種類に分けられ、スクリプトが置かれる場所が違う

XSSは、大きく反射型・格納型・DOM型の3種類に分けられます。3つの違いは、スクリプトがどこに置かれ、どの経路で閲覧者に届くかにあります。 まずは全体を表で比べてみましょう。

種類	スクリプトの置き場所	閲覧者に届く経路	典型的な発生箇所	影響範囲
反射型	罠のURLやフォームの送信内容	サーバーの応答にそのまま含まれて返る	検索結果のページ、エラーページ	罠のリンクを開いた人
格納型（持続型）	サーバーのデータベースなど	保存された内容がページに表示される	掲示板、コメント欄、問い合わせの管理画面	そのページを見た人すべて
DOM型	URLの値など、ブラウザ側のデータ	ページ内のJavaScriptが画面に書き込む	画面をJavaScriptで組み立てるページ	罠のURLを開いた人

どの型も、最後は閲覧者のブラウザでスクリプトが動く点は同じです。違いを知っておくと、開発会社と話すときに「どの画面を重点的に確認するか」を決めやすくなります。

なお、この3分類は広く使われている整理ですが、互いに重なる部分があります。OWASPは、DOM型にも反射型・格納型の両方があり得るとして、問題がサーバー側の処理にあるか（サーバーXSS）、ブラウザ側の処理にあるか（クライアントXSS）で分ける考え方も示しています。

反射型はURLなどに仕込んだスクリプトが、サーバーの応答にそのまま含まれて実行される

反射型は、罠のリンクを開いた人だけが被害を受けるタイプのXSSです。攻撃者が送り込んだスクリプトが、サーバーの応答に「はね返る」ように含まれることから、反射型と呼ばれます。

攻撃者はまず、スクリプトを含むURLを作ります。このURLをメールやSNSで送り、利用者にクリックさせます。サイト側が受け取った値をそのまま画面に表示する作りだと、返ってきたページの中でスクリプトが動いてしまいます。

起きやすいのは、検索結果のページやエラーページのように、入力した値を画面にそのまま表示する箇所です。たとえば「〇〇の検索結果」のように、検索語を画面に出すページが該当します。見覚えのないリンクを開かないことは利用者側の対策ですが、根本的にはサイト側の作りで防ぐ必要があります。

格納型はスクリプトがサーバーに保存され、そのページを見た人すべてに影響する

格納型は、スクリプトがサーバーに保存され、そのページを見た人すべてが被害を受けるタイプのXSSです。持続型と呼ばれることもあります。

攻撃者は、掲示板やコメント欄、問い合わせフォームなどにスクリプトを含む内容を投稿します。投稿がデータベースに保存され、無害化されないまま表示されると、ページを開いた人のブラウザでスクリプトが動きます。罠のリンクをクリックしなくても被害が出るため、反射型より影響が広くなりやすいのが特徴です。

情シスにとって身近なのは、問い合わせフォームの内容を社内の管理画面で開く場面です。外部から送られた問い合わせを表示したときに、情シスや社員自身のブラウザでスクリプトが動くことがあります。管理画面は社内向けだから安全、とは考えないようにしましょう。

DOM型はブラウザ上のJavaScriptの処理で起き、サーバー側の対策だけでは防ぎきれない

DOM型は、サーバーが返すHTMLではなく、ブラウザ上のJavaScriptの処理が原因で起きるタイプのXSSです。DOMとは、ブラウザがページの構造を扱うための仕組みのことです。

最近のWebサイトでは、ページ内のJavaScriptがURLの値などを読み取り、画面に書き込む処理がよく使われます。この処理で値を無害化しないまま書き込むと、URLに仕込まれたスクリプトが動いてしまいます。スクリプトがサーバーに届かない場合もあるため、サーバー側でエスケープしていても防げないことがあります。

そのため、DOM型への対策では、サーバー側の処理に加えて、画面側のJavaScriptの確認も必要です。開発会社に確認するときも、「サーバー側の対策が入っているか」だけで終わらせないことが大切です。

出典: IPA「安全なウェブサイトの作り方」／OWASP「Types of XSS」／OWASP「DOM based XSS Prevention Cheat Sheet」

IPAの届出統計では、XSSがウェブサイト脆弱性の累計56%を占めて種類別で最多

ここからは、公的な統計でXSSの位置づけを見ていきます。使うのは、IPAとJPCERT/CCが運用している、ソフトウェアやWebサイトの脆弱性に関する届出制度の統計です。この制度は2004年から届出を受け付けており、XSSの割合もそこからの累計で集計されています。

数値を見る前に、統計の性質を確認しておきましょう。この統計は、第三者が脆弱性を見つけて任意に届け出た件数をまとめたものです。IPA自身も、この統計値は本制度における届出の傾向であることに留意するよう注記しています。つまり、Web上の脆弱性全体の分布を表すものではありません。

また、脆弱性の種類別の内訳は、IPAの四半期レポートのうちPDF版にだけ掲載されています。以降の数値には、どの時点の、どの範囲の集計かを必ず添えて説明します。

2026年6月末時点の届出累計では、XSSが56%、SQLインジェクションが11%で約5倍の差がある

IPAの届出統計で、ウェブサイトの脆弱性の累計を種類別に見ると、XSSは2026年6月末時点で56%を占め、種類別で最も多い脆弱性です。2位はSQLインジェクションで、XSSとは約5倍の開きがあります。

脆弱性の種類	ウェブサイト区分の届出累計に占める割合（2026年6月末時点）	順位
クロスサイトスクリプティング（XSS）	56%	1位
SQLインジェクション	11%	2位

表の出典: IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2026年第2四半期（4月〜6月）］」PDF版をもとに作成

図の出典: IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2026年第2四半期（4月〜6月）］」PDF版のデータをもとに作成

半年前の2025年12月末時点では、XSSの割合は57%でした。ウェブサイト区分の届出累計は、2026年6月末時点で13,599件です。なお、割合の分母は不受理分などを除いた件数のため、この累計件数とは完全には一致しません。

届け出られたXSSの修正完了は5,691件で、SQLインジェクションの約5.5倍にあたる

届け出られた脆弱性が、その後どれだけ修正されたかも見てみましょう。ウェブサイト区分で修正が完了したXSSは、2026年6月末時点の累計で5,691件です。2025年12月末時点の5,681件から、半年で10件増えました。

一方、SQLインジェクションの修正完了は、2025年12月末も2026年6月末も1,040件で、変わっていません。2026年6月末時点で比べると、XSSの修正完了はSQLインジェクションの約5.5倍です。

この数字から読み取れるのは、修正完了の差（約5.5倍）が、届出累計の割合の差（約5倍）とほぼ同じ水準にあることです。XSSだけが直されずに残っている、という様子は数字からは見えません。

むしろXSSは、直近でも届出と修正が続いている種類だといえます。ただし割合は整数に丸めた値なので、比べられるのは「ほぼ同じ」というところまでです。

XSSの首位は届出が最も多かった2008年ごろから続く傾向で、57%から56%への変化は減少を意味しない

IPAによると、届出制度が始まってから届出件数が最も多かったのは2008年で、ソフトウェア製品とウェブサイトの合計で2,622件でした。IPAは、この年に件数が多かった主な理由として、XSSとDNS情報の設定不備の届出が多かったことを挙げています。

この経緯から読み取れるのは、XSSの首位は最近の現象ではなく、制度の初期から続く長い傾向だということです。ウェブサイト区分の届出は、2023〜2025年の3年間で合計1,019件でした。これは2025年12月末の累計13,467件の約7.6%にすぎず、累計の大半は過去の届出でできています。

同じ理由で、57%から56%への1ポイントの変化も、XSSが減ったことを意味しません。半年間で累計が増えたのは132件で、累計全体の約1%です。

この程度の増加では、整数に丸めた割合が1ポイント動いても丸めの範囲に収まります。累計の割合の小さな上下を、増減の傾向として読まないようにしましょう。

2026年4〜6月の新規届出65件に限ると、XSSは8件で約12%にとどまる

累計ではなく、四半期ごとの新規の届出で見ると、XSSの見え方は大きく変わります。2026年4〜6月にウェブサイトの脆弱性として届け出られたのは65件で、そのうちXSSは8件でした。計算すると約12%です。

期間	XSSの届出件数	その四半期での順位
2025年10〜12月	8件	2位
2026年4〜6月	8件	1位

表の出典: IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2025年第4四半期（10月〜12月）］」PDF版／IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2026年第2四半期（4月〜6月）］」PDF版をもとに作成

図の出典: IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2026年第2四半期（4月〜6月）］」PDF版のデータをもとに作成（約12%は件数からの計算値）

この比較から読み取れるのは、累計の56%を「いま届け出られる脆弱性の半分以上がXSS」と読むのは誤りだということです。2025年10〜12月には、XSSは2番目で、首位は「ファイルの誤った公開」という別の種類でした。

「XSSが最多」というのは、2004年からの累計で見た場合の話です。 ただし、四半期ごとの件数は少なく、特定の発見者がまとめて届け出ると大きく振れます。2四半期分だけで「XSSが減ってきている」と判断することもできません。

出典: IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2026年第2四半期（4月〜6月）］」PDF版／IPA「同［2025年第4四半期（10月〜12月）］」PDF版／IPA「同［2026年第2四半期］」／IPA「同［2025年第4四半期］」／IPA「同［2024年第4四半期］」／IPA「同［2023年第4四半期］」

ウェブサイトの脆弱性届出は2025年に178件まで減ったが、XSSのリスクが下がった証拠にはならない

ここでは、種類を問わないウェブサイトの脆弱性の届出件数を見ていきます。年間の届出件数は、2025年に178件まで減りました。

ただ、件数が減ったからといって、Webサイトが安全になったとは言えません。 届出件数の推移を読むときの注意点と、それがXSSにとってどういう意味を持つのかを順に説明します。

ウェブサイト区分の年間届出は2023年の505件から2025年の178件へ、2年で約3分の1に減った

IPAの統計で、ウェブサイト区分の年間の届出件数と修正完了件数を並べると、次のようになります。届出は2年で約3分の1に減りました。

年	届出件数（年間）	修正完了件数（年間）
2023年	505件	242件
2024年	336件	132件
2025年	178件	98件

表の出典: IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2023年第4四半期］」／IPA「同［2024年第4四半期］」／IPA「同［2025年第4四半期］」をもとに作成。いずれも種類を問わないウェブサイト区分の合計

図の出典: 上記のIPA資料（2023年・2024年・2025年の各第4四半期）のデータをもとに作成

この推移から読み取れるのは、届出の減少を安全性の向上とは読めないということです。届出は第三者が見つけて任意に届け出た件数で、脆弱なサイトの数を数えたものではありません。XSSについても、届出の減少は「XSSが起きにくくなった」ことの証拠にはなりません。

2026年上半期の届出は約130件で、すでに2025年通年の7割以上に達している

2026年に入ってからの動きも見てみましょう。ウェブサイト区分の届出累計は、2025年12月末の13,467件から、2026年6月末には13,599件になりました。この差から計算すると、2026年上半期の届出は132件です。ただし、2026年第2四半期の資料では2025年12月末の累計がわずかに修正されているため、四半期ごとの件数から数え直すと1件ほどずれます。そのため、ここでは約130件として扱います。

このうち4〜6月の届出は65件でした。上半期の約130件は、2025年通年の178件の7割以上にあたります。

この数字から読み取れるのは、届出の減少が今も続いているとは言えないということです。ただし、半年分の数字だけで「増加に転じた」と判断することもできません。XSSにとっても、件数の増減だけでリスクの高い・低いを決めないことが大切です。

IPAは脆弱性を悪用した攻撃を6年連続で10大脅威に選び、2026年版の組織向けでは4位にしている

IPAの「情報セキュリティ10大脅威 2026」の組織向けでは、「システムの脆弱性を悪用した攻撃」が4位に入っています。この脅威が選ばれたのは6年連続です。

注意したいのは、この順位は脆弱性の悪用全般についてのもので、XSSだけの順位ではないことです。10大脅威は、XSSやSQLインジェクションといった種類を分けずに、脆弱性の悪用をひとまとめにして評価しています。

このことから読み取れるのは、届出件数と10大脅威の順位は、測っているものが違うということです。届出件数は「見つかって届け出られた量」を、10大脅威は「社会への影響の大きさの評価」を表しています。XSSを含むWebサイトの脆弱性への備えは、届出件数が減っても引き続き必要だといえます。

出典: IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2023年第4四半期］」／IPA「同［2024年第4四半期］」／IPA「同［2025年第4四半期］」／IPA「同［2026年第2四半期］」／IPA「情報セキュリティ10大脅威 2026」組織編 解説書

XSS単独の被害件数や対策の導入率は公的統計に無く、分かるのは届出と修正の件数まで

ここまでIPAの統計を見てきましたが、公的統計で分かることには限りがあります。XSSについて公的統計で分かるのは、届出と修正完了の件数までです。分かることと分からないことを、表に整理しました。

公的統計で分かること	公的統計では分からないこと
届出累計に占めるXSSの割合（2026年6月末時点で56%）	XSSが原因で起きた被害の件数や被害額
XSSの修正完了件数（2026年6月末時点の累計で5,691件）	エスケープ、CSPなどXSS対策ごとの導入率（WAFは、XSS対策に限らない企業全体の導入率のみ分かる）
脆弱性の悪用全般の脅威としての評価（10大脅威2026の組織向けで4位、6年連続）	企業規模別・業種別のXSSの状況
―	XSSの修正にかかった日数の代表値（種類別の日数の分布はグラフでのみ示されている）

表の出典: IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2026年第2四半期（4月〜6月）］」PDF版／IPA「情報セキュリティ10大脅威 2026」組織編 解説書をもとに作成

10大脅威の順位は、先ほど説明したとおり脆弱性の悪用全般についてのもので、XSSを分けて扱ってはいません。

この整理から読み取れるのは、「届出件数が最も多い」ことと「被害が最も大きい」ことは別の話だということです。XSSは見つかって届け出られる件数は最も多いものの、実際の被害の規模は公的統計からは分かりません。そこで次の章では、対策を統計ではなく、技術的な理由にもとづいて組み立てていきます。

出典: IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2026年第2四半期（4月〜6月）］」PDF版／IPA「情報セキュリティ10大脅威 2026」組織編 解説書

XSS対策の基本は出力時のエスケープで、CSPやWAFは被害を抑える補助策として重ねる

XSSの対策は、「根本対策」と「被害を抑える補助策」に分けて考えると整理しやすくなります。根本対策の中心は、画面に出力する値をエスケープする作りにすることです。CSPやWAFは、それを補う位置づけになります。

対策	役割	誰が担うか
出力時のエスケープ	根本対策。紛れ込んだ値をスクリプトとして動かさない	開発会社（情シスは仕様書と受入れで確認）
入力値の検証	補助策。想定外の値を受け付けない	開発会社
CSP	補助策。実行してよいスクリプトの読み込み元を制限する	開発会社・サーバーの管理者
Cookieの HttpOnly 属性	補助策。スクリプトからCookieを読めないようにする	開発会社・サーバーの管理者
WAF	補助策。攻撃に典型的な通信を遮断する	情シス・インフラの管理者

画面に出力する値はすべてエスケープし、入力値の検証と組み合わせる

XSS対策の中心は、画面に出力する値をすべてエスケープすることです。エスケープとは、HTMLとして特別な意味を持つ記号を、画面に表示するためだけの文字に置き換える処理のことです。

たとえば「<」や「>」のような記号は、そのまま出力するとHTMLのタグとして扱われます。エスケープしておけば、利用者が入力したスクリプトも、ただの文字として画面に表示されるだけになります。なお、出力する場所がHTMLの本文か、タグの属性か、URLか、JavaScriptの中かによって、必要な処理は変わります。

IPAの「安全なウェブサイトの作り方」は、エスケープのほかにも、リンク先などのURLを出力するときは「http://」「https://」で始まるものだけを許可すること、script要素の中身を外部からの入力で組み立てないこと、応答のヘッダーで文字コードを指定することを、根本的な対策に挙げています。また、掲示板などでHTMLの入力を許可する場合は、エスケープすると表示が崩れるため、許可したタグだけを残す処理（ホワイトリスト方式）で対応します。

入力値の検証は、想定外の値をそもそも受け付けないための補助的な対策です。ただし、入力の段階だけで危険な値をすべて取り除くのは難しく、これだけでは防ぎきれません。

開発フレームワークには、自動でエスケープする機能を備えたものがあります。情シスとしては、この機能を外していないかを開発会社に確認するのがよいでしょう。ただし、多くのフレームワークには、エスケープせずにHTMLをそのまま出力する機能も用意されています。こうした機能を使っている箇所は自動エスケープの対象外になるため、どこで使っているかもあわせて確認しましょう。

CSPとHttpOnly属性は、スクリプトが紛れ込んだときの被害を小さくする

CSPとHttpOnly属性は、スクリプトが紛れ込んでしまったときに、被害を小さくするための設定です。どちらもエスケープの代わりにはなりません。

CSP（Content Security Policy）は、ブラウザが実行してよいスクリプトの読み込み元を、サイト側から指定する仕組みです。設定しておくと、指定していない場所から読み込まれたスクリプトの実行をブラウザが止めます。ページに直接書き込まれたスクリプト（インラインスクリプト）も、それを許可しない設定にしていれば止められます。ただし、既存のサイトに後から入れると、正規の機能まで止まることがあるため、設計の段階から考えておくのが理想です。

HttpOnly属性は、CookieをJavaScriptから読み取れないようにする設定です。XSSが起きても、ログイン状態を保つセッションCookieが盗まれにくくなります。ただし、Cookieの盗用以外の被害、たとえば偽の情報の表示や、利用者の画面上での不正な操作は防げません。根本対策に漏れがあった場合に備えて、この2つも重ねておきましょう。

WAFを導入している企業は2025年時点で19.5%にとどまり、XSS対策としては補完の位置づけ

WAF（Web Application Firewall）は、Webサイトへの通信の中身を見て、攻撃に典型的なパターンを遮断する仕組みです。総務省の調査では、WAFを導入している企業の割合は2025年時点で19.5%でした。常用雇用者100人以上の企業を対象とする調査で、インターネットを利用している企業の回答です。2024年は17.4%です。

この数値は企業全体でのWAFの導入状況で、XSS対策としての導入に限ったものではありません。WAFは既知の攻撃パターンを止める補完策で、エスケープの代わりにはなりません。 攻撃の書き方を少し変えられると、検知をすり抜けることもあります。

WAFの位置づけは、出典によって温度差があります。IPAは、すぐに改修できない場合などに攻撃の影響を減らす運用面の対策として、WAFを紹介しています。一方でOWASPは、WAFは根本原因を解消せず、回避の手口も見つかり続けるとして、XSSを防ぐ手段としては推奨していません。

また、DOM型のXSSのように、攻撃の通信がサーバーに届かない場合は、WAFでは検知しにくくなります。WAFは「根本対策をしたうえで、さらに重ねる守り」として考えてください。

出典: 総務省「令和7年通信利用動向調査の結果（概要）別紙2」／総務省「令和7年通信利用動向調査報告書」／IPA「安全なウェブサイトの作り方」／OWASP「Cross Site Scripting Prevention Cheat Sheet」

情シスは発注時の仕様書と受入れ確認、公開後の定期点検でXSS対策を確かめる

自社でコードを書かない情シスでも、XSS対策のためにできることはあります。発注時の仕様書、納品前の受入れ確認、公開後の点検の3つの場面で、対策が入っているかを確かめることです。まずは、発注時に確認したい項目をチェックリストにまとめました。

仕様書には出力時のエスケープ、CSPの設定、リリース前の脆弱性診断の3点を明記する

同じくらいの規模の企業が、XSS対策をどこまで実施しているかを示す公的統計はありません。そのため、自社の要件は「他社並み」を基準にするのではなく、確認項目を積み上げて決める必要があります。仕様書には、出力時のエスケープ、CSPの設定、リリース前の脆弱性診断の3点を明記しておきましょう。

1点目のエスケープは、「画面に出力する値は、出力する場所に応じてすべてエスケープすること」と依頼します。管理画面や社内向けの画面も対象に含めることを、あわせて書いておくと安心です。

2点目のCSPは、「CSPを設定し、設定内容を納品物に含めること」と書きます。3点目は、「リリース前に脆弱性診断を行い、XSSを含む結果と対応状況を報告すること」と依頼します。口頭で伝えるだけでなく、文書に残しておくことが大切です。

受入れ時は、入力値がそのまま表示される画面と、問い合わせ内容を開く管理画面を重点的に確認する

受入れ確認や脆弱性診断では、すべての画面を同じ重さで見るのは大変ですよね。XSSが起きやすい画面を、診断の対象に必ず含めるようにしましょう。

まず押さえたいのは、格納型が起きやすい画面です。問い合わせ内容を開く管理画面、コメントやレビューを表示する画面、社内向けの一覧画面などが当てはまります。外部の人が入力した内容が、保存されたあとに表示される画面だと考えると分かりやすいです。

次に、反射型が起きやすい画面です。検索結果のページや、入力した値をそのまま返すエラーメッセージの画面が該当します。

診断会社に依頼するときは、こうした画面が対象範囲に入っているかを見積もりの段階で確認してください。診断の手順そのものは、専門の診断会社に任せて問題ありません。

公開後はCMSやプラグインを更新し、外部に公開しているサイトを一覧で把握しておく

XSSは、自社で作った部分だけでなく、CMSやプラグインの脆弱性としても見つかります。そのため、公開後もCMSやプラグインを更新し続けることが欠かせません。 更新作業を保守契約の範囲に含めておくと、対応が漏れにくくなります。

もう一つ大切なのが、外部に公開しているIT資産の把握です。過去のキャンペーンサイトや、使われなくなった古いフォームが残っていないかを定期的に棚卸ししましょう。担当者が把握していないサイトは、更新も診断もされないまま放置されがちです。

外部から脆弱性の連絡を受けることもあります。IPAの届出制度では、IPAが届出の内容を確認したうえでサイトの運営者に連絡し、修正されたかどうかを運営者からの報告などで確認します。

XSSでは、2026年6月末時点の累計で5,691件の修正が完了しています。連絡を受けたら放置せず、開発会社と相談して対応を進めてください。

出典: IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2026年第2四半期（4月〜6月）］」PDF版

まとめ: XSSは届出件数が最も多い脆弱性で、対策は開発時のエスケープと発注側の確認で担保する

XSSは、Webページにスクリプトを紛れ込ませて、閲覧者のブラウザで実行させる攻撃です。IPAの届出統計では種類別で最も多い脆弱性ですが、その数値は累計で見た場合の話です。 この記事の要点を振り返ります。

• XSSは、入力された値が無害化されずに画面に出力されることで起き、反射型・格納型・DOM型の3種類がある
• IPAの届出統計では、2026年6月末時点でウェブサイト脆弱性の累計の56%を占める。ただし2026年4〜6月の新規届出65件のうちXSSは8件で、約12%だった
• 根本対策は出力時のエスケープで、CSP、HttpOnly属性、WAFは被害を抑える補助策として重ねる
• 情シスは、仕様書への明記、受入れ時の重点確認、公開後の更新と資産の棚卸しで対策を確かめる

XSSは、SQLインジェクションと並ぶWeb攻撃の二大手口です。攻撃される場所は違いますが、どちらも開発時の作りで防ぐのが基本という点は共通しています。自社のWebサイトや問い合わせフォームについて、まずは開発会社に対策の状況を確認するところから始めてみてください。

出典: IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2026年第2四半期（4月〜6月）］」PDF版／IPA「同［2026年第2四半期］」

セキュリティの基礎を学ぶなら「情シスカレッジ」

XSSのような脆弱性について開発会社と話すには、Webの仕組みやセキュリティの基礎用語の理解が欠かせません。とはいえ、新任やひとり情シスの方ほど、まとまった学習の時間は取りにくいですよね。

「情シスカレッジ」は、新人・ひとり情シスのためのマイクロラーニングLMSです。数分の動画と小テストで、業務の合間に少しずつ学べます。

導入は5名から可能で、請求書払いにも対応しています。初期設定はおよそ10分で完了します。

情シスカレッジの詳細を見る

※出典

• 情報処理推進機構「ソフトウェア等の脆弱性関連情報に関する届出状況［2026年第2四半期（4月〜6月）］」PDF版
• 情報処理推進機構「ソフトウェア等の脆弱性関連情報に関する届出状況［2025年第4四半期（10月〜12月）］」PDF版
• 情報処理推進機構「ソフトウェア等の脆弱性関連情報に関する届出状況［2026年第2四半期（4月〜6月）］」
• 情報処理推進機構「ソフトウェア等の脆弱性関連情報に関する届出状況［2025年第4四半期（10月〜12月）］」
• 情報処理推進機構「ソフトウェア等の脆弱性関連情報に関する届出状況［2024年第4四半期（10月〜12月）］」
• 情報処理推進機構「ソフトウェア等の脆弱性関連情報に関する届出状況［2023年第4四半期（10月〜12月）］」
• 情報処理推進機構「情報セキュリティ10大脅威 2026」組織編 解説書
• 総務省「令和7年通信利用動向調査の結果（概要）別紙2」
• 総務省「令和7年通信利用動向調査報告書」
• 情報処理推進機構「安全なウェブサイトの作り方」
• OWASP「Types of XSS」
• OWASP「Cross Site Scripting Prevention Cheat Sheet」
• OWASP「DOM based XSS Prevention Cheat Sheet」