クロスサイトスクリプティング（XSS）とは？ わかりやすく10分で解説

はじめに

XSS（クロスサイトスクリプティング）は、Webアプリケーションの表示処理やDOM操作の不備を突き、攻撃者が用意したスクリプトを利用者のブラウザ上で実行させる攻撃です。問題の中心は、攻撃者の端末ではなく、正規サイトを閲覧した利用者のブラウザでコードが動く点にあります。

被害は画面改ざんにとどまりません。偽フォームによる入力誘導、Cookieやトークンの悪用、ログイン済み状態を使った不正操作につながることがあります。とくに、入力内容を画面へ反映する機能が多いサービスほど、対策の抜けが事故に直結しやすくなります。

XSS（Cross-Site Scripting）とは？

XSSとは、利用者から受け取った値や外部データを、ブラウザで解釈される形のまま出力してしまうことで、意図しないスクリプト実行を招く脆弱性・攻撃の総称です。代表的な実行環境はJavaScriptですが、問題の本質は「危険な値が、実行可能な文脈で表示されること」にあります。

なぜ起きるのか

原因は「入力があること」自体ではなく、出力時の扱いにあります。検索結果、コメント欄、プロフィール、管理画面の一覧、URLパラメータ、クライアント側テンプレート生成などで、値をそのままHTML本文、属性値、JavaScript、URLへ埋め込むと、攻撃用の文字列まで実行対象になることがあります。

どのような被害につながるか

• 偽の案内やフォームを表示し、利用者に入力を促す
• ログイン済みセッションを悪用して、設定変更や送信処理を実行する
• ページ内容を書き換え、別サイトや不正なダウンロード先へ誘導する
• 管理画面で成立し、権限の高い利用者の操作を悪用する

クロスサイトスクリプティングの種類

実務では、XSSは反射型、保存型、DOM型の3つで整理されることが多くあります。厳密には重なる場合もありますが、発生箇所と対策の見方を分けるには有効な整理です。

反射型XSS（Reflected XSS）

URLパラメータやフォーム入力が、そのリクエストに対するレスポンスへ即座に反映されることで成立する型です。細工したURLをメールやSNSで開かせる手口と相性がよく、利用者の操作が実行条件になりやすい点に特徴があります。

保存型XSS（Stored XSS）

攻撃者の入力がサーバー側へ保存され、その内容を閲覧した別の利用者のブラウザでスクリプトが実行される型です。掲示板、コメント欄、プロフィール、問い合わせ履歴、管理画面の一覧表示など、入力を蓄積する機能で起きやすく、一度混入すると影響範囲が広がりやすくなります。

DOM型XSS（DOM-based XSS）

サーバーのレスポンス生成よりも、ブラウザ上のJavaScriptがDOMを組み立てる過程で発生する型です。たとえば、URL断片や検索文字列を不適切にDOMへ挿入すると成立します。サーバー側の対策だけでは拾い切れないことがあり、フロントエンド実装の確認が欠かせません。

なぜXSSは危険なのか

正規サイト上で成立する

XSSは、利用者が正規サイトを開いている状態で起こります。そのため、利用者は警戒しにくく、偽のメッセージや入力欄が表示されても「サイト側の画面だ」と受け取りやすくなります。信頼されているサービスほど、攻撃の成功率が上がりやすい構造です。

ログイン後の権限を悪用される

利用者がすでにログインしている場合、スクリプトはその権限の範囲で動きます。これにより、単なる画面改ざんだけでなく、セッションハイジャックに近い形で操作が悪用されることがあります。管理画面や社内向け画面で起きると、影響が大きくなりやすくなります。

被害が利用者と運営側の両方へ及ぶ

利用者は認証情報や個人情報を奪われるおそれがあり、運営側は問い合わせ対応、調査、改修、再発防止、信頼低下への対応を迫られます。したがって、XSSは「表示の不具合」ではなく、運用と信用に影響する脆弱性として扱う必要があります。

似た脆弱性との違い

XSSとクロスサイトリクエストフォージェリの違い

XSSは利用者のブラウザ上でスクリプトを動かす攻撃です。CSRFは利用者のブラウザに、意図しないリクエストを送らせる攻撃です。両方ともログイン済み状態の悪用につながりますが、XSSはページ内で任意のスクリプトを実行できる点で影響範囲が広くなりやすくなります。

XSSとSQLインジェクションの違い

SQLインジェクションはサーバー側のデータベース処理を不正に操作する脆弱性です。XSSはブラウザ側でスクリプトを実行させる脆弱性です。どちらも入力の扱いが発端になりやすいものの、攻撃が成立する層と被害の出方は異なります。

クロスサイトスクリプティングの対策

出力先の文脈に応じてエスケープする

XSS対策の基本は、入力値を一律に置換することではなく、出力先の文脈に応じたエスケープを行うことです。HTML本文、属性値、JavaScript文字列、URLでは、安全に出力するための処理が異なります。入力チェックだけで済ませようとすると、抜けが残りやすくなります。

危険なDOM操作を避ける

フロントエンドでは、文字列をそのままHTMLとして挿入する実装を避け、テキストとして扱うAPIやフレームワーク標準の機能を優先します。DOM型XSSは、サーバー側のフィルタでは見つかりにくいため、画面側の実装を別枠で確認した方が漏れを減らせます。

CSPを補助策として使う

Content Security Policy（CSP）は、ブラウザが読み込んでよいスクリプト元や実行条件を制限する仕組みです。XSSの影響を抑える補助策として有効ですが、CSPだけで脆弱性自体が消えるわけではありません。出力処理の修正と併用して初めて効果が安定します。

フレームワーク標準機能とライブラリを優先する

テンプレートの自動エスケープ、サニタイズ用ライブラリ、フレームワークが推奨する安全な実装を使うと、独自実装より抜けを減らしやすくなります。独自の置換ルールや場当たり的なフィルタは、例外パターンに弱く、保守時の再発原因になりがちです。

WAF・診断・コードレビューを補助線にする

WAFは一部の攻撃パターンを遮断できますが、DOM型XSSや文脈依存の問題まで完全に止められるわけではありません。定期的な脆弱性診断、コードレビュー、ログ確認を組み合わせ、実装と運用の両方で確認する体制を持った方が安定します。

被害を広げにくい設計も入れる

CookieへHttpOnlyやSameSiteを付ける、権限を細かく分ける、重要操作で再認証を求める、といった補助策は、XSSが起きた後の被害範囲を抑える方向で効きます。ゼロか百かで考えず、成立しにくくし、成立しても広がりにくくする設計を重ねることが実務では有効です。

まとめ

XSSは、Webアプリケーションの表示処理やDOM操作の不備を突いて、利用者のブラウザ上で意図しないスクリプトを動かす攻撃です。反射型、保存型、DOM型のどれであっても、入力値を実行可能な形で出力する実装があると成立します。

対策の中心は、出力先ごとの適切なエスケープ、安全なDOM操作、CSPの併用、標準機能の活用です。あわせて、診断、コードレビュー、ログ監視を継続し、コメント欄、検索、管理画面、クライアント側テンプレートのような「入力を表示する箇所」から優先して点検すると、事故につながる穴を見つけやすくなります。