※本記事にはアフィリエイトリンクが含まれます。詳しくはプライバシーポリシー・広告掲載についてをご覧ください。
「自社のWebサイトが改ざんされた」「ユーザーのセッション情報が盗まれた」——そんな被害の背後に潜む脆弱性の一つが、XSS(クロスサイトスクリプティング)です。IPAの「情報セキュリティ10大脅威 2026」でもWebアプリ脆弱性攻撃が引き続き上位にランクインしており、XSSはSQLインジェクションと並んで最も報告件数が多い脆弱性です。本記事では、XSSの仕組みから最新の攻撃手口、そして企業が今すぐ実施すべき対策まで、エンジニアと非エンジニア双方が理解できるように解説します。
XSS(クロスサイトスクリプティング)とは何か
XSSとは、攻撃者が悪意あるスクリプト(主にJavaScript)をWebページに埋め込み、そのページを閲覧したユーザーのブラウザ上でスクリプトを実行させる攻撃手法です。「クロスサイト(Cross-Site)」という名称は、攻撃者が第三者のサイトを踏み台にする旧来の手口に由来しており、現在は同一サイト内での攻撃が主流ですが、名称がそのまま定着しています。
XSS攻撃が成立する根本原因は、ユーザー入力をそのままHTMLとして出力する処理にあります。検索フォームやコメント欄など、入力値をそのままページに表示する箇所が存在する場合、攻撃者はそこに`<script>`タグを含む文字列を送り込むことができます。
XSSで実現される主な攻撃内容
- セッションハイジャック:`document.cookie`を外部サーバーに送信し、ログイン済みユーザーになりすます
- フィッシングページへのリダイレクト:正規サイト上に偽ログイン画面を表示して認証情報を窃取
- マルウェア配布:Drive-by Download攻撃でユーザー端末にマルウェアをインストール
- Webサイト改ざん:ページ内容を書き換えてブランドイメージを毀損
- キーロガー設置:入力フォームに対してキー入力を記録・送信
XSSの3種類:反射型・格納型・DOM型の違い
XSSは攻撃の仕組みによって大きく3種類に分類されます。それぞれの特性を理解することが、適切な対策を選択するうえで重要です。
① 反射型XSS(Reflected XSS)
攻撃者が細工したURLにユーザーがアクセスすることで発動する、最も一般的なXSSです。悪意あるスクリプトはサーバーに保存されず、URLのパラメーターとして送信されたスクリプトがそのままレスポンスに反射(Reflect)されてブラウザで実行されます。フィッシングメールや短縮URLを利用してターゲットを誘導するのが典型的な手口です。

Example Domain
② 格納型XSS(Stored XSS / Persistent XSS)
攻撃スクリプトがデータベースやファイルに保存され、ページを閲覧するすべてのユーザーに影響を与えるタイプです。コメント機能、プロフィール欄、掲示板など、ユーザー投稿内容を表示する機能に存在します。一度埋め込まれると多数のユーザーが被害を受けるため、3種類の中で最も危険性が高いとされています。2023年に発覚した某大手ECサイトの被害事例でも、この格納型XSSが悪用されました。
③ DOM型XSS(DOM-based XSS)
サーバーを介さず、クライアントサイドのJavaScriptがDOMを操作する際に発生するXSSです。`document.URL`、`location.hash`、`innerHTML`などのDOM APIを通じて悪意あるコードが実行されます。サーバーログに攻撃の痕跡が残りにくいため、検出・調査が困難という特徴があります。SPAやReact/Vue/Angularを使ったフロントエンドで特に注意が必要です。
2026年の最新XSS攻撃トレンド
XSS攻撃は年々高度化しています。2026年現在、特に注目すべきトレンドをIPAおよびJPCERT/CCの報告をもとに整理します。
AIを活用したXSSペイロード生成
攻撃者が生成AIを使ってWAF(Webアプリケーションファイアウォール)のフィルタリングを回避するXSSペイロードを自動生成するケースが増加しています。従来のシグネチャベースのWAFでは検出困難なケースも報告されており、WAFのルールの継続的な更新と、根本的なコードレベルの対策の併用が不可欠です。
サプライチェーン経由のXSS(Stored XSS in CDN)
外部CDNやサードパーティライブラリ(npm等)を通じてXSSスクリプトが埋め込まれる「サプライチェーンXSS」が増加しています。2024年に発覚したpolyfill.ioへの攻撃では、世界中のWebサイトが悪意あるスクリプトを配信させられました。自社コードだけでなく、依存ライブラリのセキュリティ管理も重要です。
マークダウン・リッチテキストエディタの脆弱性悪用
CMSやSaaSで広く使われるリッチテキストエディタやマークダウンパーサーの実装不備を狙ったXSS攻撃が増えています。`javascript:` スキームを使ったリンク属性や、SVG要素内のスクリプトを悪用する手口が報告されています。
XSS対策の基本:エスケープ処理とバリデーション
XSS対策の根本は、ユーザー入力をHTMLとして解釈させないことです。具体的には以下の対策を実装します。
出力時のHTMLエスケープ(最重要)
ユーザー入力をHTMLに出力する際は、必ず特殊文字をエスケープします。最低限以下の5文字を変換します。
| 文字 | エスケープ後 |
|---|---|
| & | & |
| < | < |
| > | > |
| “ | " |
| ‘ | ' |
現代のWebフレームワーク(React、Vue、Angular、Rails、Laravel等)はテンプレートエンジンでデフォルトエスケープを行いますが、意図せず生のHTML出力をしていないか確認することが重要です。ReactでいえばdangerouslySetInnerHTML、VueでいえばV-htmlが危険箇所です。
入力バリデーション
入力値を受け取る際に、許可する文字・形式をホワイトリスト方式で検証します。例えばメールアドレスはメール形式のみ、電話番号は数字・ハイフンのみを許可します。ブラックリスト方式(`<script>`を弾く等)は回避されやすいため非推奨です。
textContentの使用(JavaScript)
JavaScriptでDOM操作をする場合、`innerHTML`の代わりに`textContent`または`innerText`を使用します。これにより文字列がHTMLとして解釈されず、スクリプトが実行されません。
// 危険な実装
element.innerHTML = userInput;
// 安全な実装
element.textContent = userInput;
XSS対策の応用:CSP・Cookie設定・DOMPurify
Content Security Policy(CSP)の設定
CSP(コンテンツセキュリティポリシー)は、ブラウザが実行を許可するリソースの種類・送信元をHTTPヘッダーで制御する仕組みです。適切なCSPを設定することで、攻撃者がXSSに成功してもスクリプトの実行をブロックできます。
# Nginxでの設定例
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'nonce-{RANDOM}'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; object-src 'none';"
特に`script-src ‘unsafe-inline’`は避け、`nonce`または`hash`ベースのCSPを採用することで、インラインスクリプトの実行を制限できます。Google、GitHub等の主要サービスはすべてCSPを実装しています。
Cookie の HttpOnly・Secure・SameSite 属性
XSS攻撃でセッションCookieが盗まれるリスクを軽減するため、Cookie属性を適切に設定します。
- HttpOnly:JavaScriptからのCookieアクセスを禁止(`document.cookie`での取得不可)
- Secure:HTTPS接続時のみCookieを送信
- SameSite=Strict or Lax:クロスサイトリクエスト時のCookie送信を制限しCSRF対策にもなる
DOMPurify によるサニタイズ
リッチテキストエディタ等でHTMLの入力を許容しなければならない場合は、DOMPurify等のサニタイズライブラリを使用します。DOMPurifyは信頼できるXSSサニタイザとして広く採用されており、危険なタグ・属性を除去しながら安全なHTMLを返します。
import DOMPurify from 'dompurify';
const clean = DOMPurify.sanitize(userInput);
element.innerHTML = clean; // 安全
フレームワーク別XSS対策チェックポイント
React
- `dangerouslySetInnerHTML`の使用箇所を全件レビューし、使用する場合はDOMPurifyでサニタイズ
- URLを`href`に使用する場合は`javascript:`スキームをブロック(`href={sanitizeUrl(url)}`)
- 依存ライブラリのXSS脆弱性を`npm audit`で定期チェック
Vue.js
- `v-html`ディレクティブは必要最小限に限定し、使用前にサニタイズ
- テンプレート内の`{{ }}`構文はデフォルトでエスケープされるため安全
- `v-bind`で属性にユーザー入力を使用する場合はURLバリデーションを実施
WordPress
- 出力時は`esc_html()`・`esc_attr()`・`esc_url()`・`wp_kses()`を用途に応じて使用
- プラグイン・テーマは公式ディレクトリから入手し、常に最新版を維持
- 管理者アカウントへの二要素認証(2FA)を有効化してXSS経由の乗っ取りを防止
詳しくはSQLインジェクション対策ガイドやフィッシング攻撃対策ガイドも合わせてご覧ください。
脆弱性診断・WAFによるXSS検出と防御
定期的な脆弱性診断の実施
XSSをはじめとするWebアプリ脆弱性を発見するために、定期的な脆弱性診断が有効です。ツールを使った自動診断と、専門家によるペネトレーションテスト(侵入テスト)を組み合わせるのが理想です。OWASPが提供する無料ツール「ZAP(Zed Attack Proxy)」は、Webアプリの自動スキャンに広く使われています。
WAF(Webアプリケーションファイアウォール)の導入
WAFはHTTPリクエスト・レスポンスを検査し、XSSを含む攻撃パターンをブロックします。クラウド型WAF(AWS WAF、Cloudflare WAF等)はシグネチャの自動更新や、機械学習ベースの異常検知が利用でき、中小企業でも比較的容易に導入できます。ただしWAFはあくまで多層防御の一層であり、コードレベルの対策との併用が必須です。
セキュリティヘッダーの設定確認
X-XSS-Protectionヘッダーは旧来ブラウザのXSSフィルター制御に使われていましたが、現代のブラウザでは廃止されています。代わりにCSPが現代標準の防御手段です。`securityheaders.com`等の無料ツールで自社サイトのヘッダー設定を確認できます。
IPAが公開している脆弱性対策情報(IPA)や情報セキュリティ10大脅威 2026(IPA)も定期的に参照し、最新の脅威情報をキャッチアップしましょう。
おすすめセキュリティ対策ツール
本記事で紹介した対策を実施するうえで役立つ製品をご紹介します。
🛡️ まず今日から始めるなら:エンドポイント保護ソフトの導入
XSS攻撃でマルウェアが配布された場合の被害を最小化するには、エンドポイントセキュリティソフトの導入が第一歩です。信頼性の高いセキュリティソフトで端末を守りましょう。
- — 誤検知が少なく軽量。中小企業に人気のコスパ重視セキュリティソフト
- — 日本語サポートが充実。国産ソフトで中小企業導入実績多数
- — 世界最大手のセキュリティベンダー。VPN機能も含む総合対策
※ 上記はアフィリエイトリンクです。料金・機能は各公式サイトで必ずご確認ください。
✅ おすすめのセキュリティソフト
※ アフィリエイトリンクを含みます。料金・詳細は各公式サイトでご確認ください。
まとめ:XSS対策のチェックリスト
XSS攻撃は種類・手口が多岐にわたりますが、基本的な対策を体系的に実装することで大幅にリスクを低減できます。
- ✅ 出力エスケープ:すべてのユーザー入力出力箇所でHTMLエスケープを実施
- ✅ 入力バリデーション:ホワイトリスト方式でフォーム入力を検証
- ✅ CSP設定:適切なContent-Security-Policyヘッダーを設定
- ✅ Cookie属性:HttpOnly・Secure・SameSiteを必ず設定
- ✅ innerHTML回避:JavaScriptのDOM操作はtextContentを優先
- ✅ ライブラリ更新:依存パッケージの脆弱性を定期スキャン
- ✅ 脆弱性診断:年1回以上のWebアプリ診断を実施
XSSは「古い脆弱性」と思われがちですが、実装の複雑化やフロントエンド技術の多様化により、2026年現在も継続的に発見・悪用されています。開発チーム全体でセキュアコーディングの文化を育て、継続的な対策を維持することが企業のWebセキュリティの根幹です。
関連記事
・SQLインジェクション攻撃の手口と対策ガイド
・フィッシング攻撃の最新手口と企業向け対策ガイド


コメント