XSSとは｜仕組み・3種類の攻撃・実装対策とCSP設計

XSS（クロスサイトスクリプティング）とは｜基本の仕組み

XSSは、攻撃者が用意したJavaScriptを、利用者のブラウザ上で「そのサイトのオリジン」として実行させる脆弱性です。オリジンが一致するため、ブラウザは同一オリジンポリシーで守っているはずのCookieやローカルストレージ、DOMへ攻撃者コードがアクセスできてしまいます。IPAは「ウェブページへの出力処理に問題がある場合、そのウェブページにスクリプト等を埋め込まれてしまう問題」と定義しています（IPA 安全なウェブサイトの作り方 クロスサイト・スクリプティング）。

なぜサーバ側は無傷でも危険なのか

被害はサイト運営者ではなく閲覧者に降りかかります。しかし、閲覧者が管理者権限を持つユーザーだった場合、管理画面のトークンが漏れて実質的にサーバまで到達する経路が成立します。「利用者への被害」と「運営への被害」を切り離して考えるのは危険です。

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

SQLインジェクションはサーバ側のクエリ生成の不備、XSSはブラウザ側のHTML/JavaScript生成の不備で発生します。両者は「入力を検証せずに構文へ埋め込む」という点で同型の脆弱性ですが、対策の作法は異なります。SQL側の詳細はSQLインジェクションとは｜仕組み・主要攻撃4種・実装対策と検知方法で整理しています。

攻撃者が狙う3つの成果物

• Cookie/セッションIDの窃取：HttpOnlyが付いていないCookieなら「document・cookie」の読み出しでセッションを乗っ取れる

• DOM操作による偽画面表示：ログインフォームを差し替えて認証情報を盗む

• CSRFトークンの回収と横展開：XSS単独ではなく他の脆弱性の入り口として使われる

ミニFAQ｜クライアント側のみの脆弱性か

Q. XSSはフロントエンド担当だけが気にすればよい脆弱性ですか？

いいえ。サーバ側テンプレートで出力する箇所（Django、Laravel Blade、ERB、Thymeleafなど）でも同じ問題が起きます。フロントエンド／バックエンドを問わず「HTMLに何を書き出しているか」を追える人が対応します。

XSSの3種類｜反射型・格納型・DOMベース

XSSは、悪意あるスクリプトがどこで生成・保管・実行されるかによって3種類に分類されます。攻撃の起点も検知の難しさも異なるため、必ず区別して設計してください。

反射型XSSの典型シナリオ

攻撃者が細工したURLを標的にメールやSNSで送り、クリックさせた瞬間にスクリプトが実行されるパターンです。検索キーワードや404ページに入力値をそのまま表示するサイトは要注意です。フィッシングと組み合わせて使われることが多く、単体では気付きにくい特徴があります。

格納型XSSの典型シナリオ

BBS・レビュー・通知などに埋め込まれたスクリプトが、閲覧するすべてのユーザーに配信されます。管理画面上に格納されて管理者が閲覧した瞬間に管理権限を取られるケースもあり、影響範囲は3種類の中でもっとも広くなりがちです。

DOMベースXSSの典型シナリオ

サーバのレスポンス自体は無害でも、クライアント側のJavaScriptが 「location・hash」 や 「document・referrer」 から値を取り出し、「innerHTML」 や 「document・write」 に流し込んだ結果として発生します。サーバのアクセスログに攻撃文字列が残らないため、WAFやSIEMからも見えにくい厄介な種類です。

3種類の見分け方（フロー図の代わり）

• 「URLを踏んだ瞬間だけ発火」→ 反射型が有力

• 「別のユーザーが後日踏んで発火」→ 格納型が有力

• 「サーバのレスポンスは変わっていないのに発火」→ DOMベースを疑う

ミニFAQ｜Self-XSSは脆弱性か

Q. 開発者ツールのコンソールに貼り付けて実行するSelf-XSSは脆弱性として扱いますか？

一般には脆弱性としてカウントされません。ただし、SNS詐欺で「このコードをコンソールに貼ってください」と誘導される事例があるため、Facebookなどは実際にコンソール警告を表示しています。バグバウンティの対象外になるケースが多い点も覚えておくとよいでしょう。

国内外の被害事例と影響範囲

XSSは古典的な脆弱性ですが、大規模サービスでも継続して発見されています。IPAが毎年公開する「情報セキュリティ10大脅威」でもWebアプリの脆弱性として上位に残り、CVE登録数も減っていません。

よくある被害パターン

• セッションハイジャック：ログイン中のセッションを乗っ取り、そのユーザーになりすまして操作

• フィッシング誘導：正規サイト内に偽ログインフォームを差し込み、認証情報を送信させる

• 仮想通貨・ECサイトの残高操作：XSSでAPIトークンを盗み、送金APIを直接叩く

• 管理画面経由の内部侵害：管理者権限のあるCookieを取得し、サーバ側のRCEにつなげる

影響を数値で捉える

金銭被害の目安は個別事例で幅が大きく、報告例のない被害も多いため公表額だけで判断すべきではありません。JVN iPediaや各社セキュリティレポートに公開されている事例では、Cookie窃取から始まったインシデントが最終的にRCEや情報流出につながっているケースが目立ちます。詳細な近年の統計はIPA 情報セキュリティ10大脅威でカテゴリごとに整理されています。

ミニFAQ｜静的HTMLサイトなら安全か

Q. データベースを使わないLP・静的HTMLサイトはXSSの心配は不要ですか？

CMSを使わない完全静的なHTMLで、外部の入力を一切表示しないなら発生しません。ただし、コメントフォーム・チャットボット埋め込み・広告タグ・アクセス解析タグなどサードパーティスクリプトを載せた瞬間に攻撃面が生まれます。

根本的対策｜出力コンテキスト別のエスケープ設計

XSS対策の中心は「入力の検証」ではなく「出力時のエスケープ」です。入力バリデーションだけでは不十分で、値がどのコンテキスト（HTML本文・属性値・JavaScript・URL・CSS）に埋め込まれるかで、必要なエスケープ関数が変わります。

コンテキスト別の安全な変換

テンプレートエンジンの自動エスケープを崩さない

多くのモダンなテンプレートエンジンはHTML本文向けのエスケープを自動で行います。React/JSXの 「{value}」、Vue の 「{{ value }}」、Django テンプレートや Rails ERB の 「〈%= %〉」 などが該当します。危険なのは、これらを迂回する記法（Reactの 「dangerouslySetInnerHTML」、Vueの 「v-html」、Djangoの 「{% autoescape off %}」）を安易に使ったときです。

「innerHTML」 と 「document・write」 に近づかない

DOM操作でHTMLを組み立てるとき、「innerHTML」 に文字列連結した値を代入するとDOMベースXSSに直結します。テキストを差し込みたいなら 「textContent」、要素を作りたいなら 「createElement」 と 「setAttribute」 を使い分けるのが原則です。

入力バリデーションは「補助」として設計する

メール形式チェックや文字数制限は品質向上に有効ですが、XSS対策の主軸には置きません。理由は、正しい形式のペイロード（例：イベントハンドラ属性でリモートスクリプトを取得する構文を含む正規のURL）は入力段階で拒否できないからです。IPAも同様に、根本対策として出力側の処理を推奨しています（IPA 安全なウェブサイトの作り方）。

DOMPurifyを使うのが自然な場面

ユーザーにHTMLを書かせる仕様（リッチテキストエディタ、Markdown→HTML変換）では、単純なエスケープが使えません。この場合はサニタイズライブラリで危険なタグ・属性・スキームを除去します。JavaScriptではDOMPurifyがデファクトです。自作の正規表現でタグを削るアプローチは、パーサ差分の突破で回避されやすいため避けてください。

ミニFAQ｜React使えばXSS対策は不要か

Q. Reactを使えばXSSは自動的に防げますか？

JSX内の 「{value}」 はエスケープされますが、「dangerouslySetInnerHTML」、「href」属性に 「javascript：」 スキームが入るケース、遷移先URLをユーザー入力から組み立てる実装などは自分で対策する必要があります。フレームワーク任せにできる範囲と、開発者が意識する範囲を分けて理解してください。

保険的対策｜CSP・HttpOnly・Trusted Typesの使い分け

保険的対策は根本対策の代替ではなく、「もし出力エスケープに漏れがあってもスクリプトが動かない／被害が限定される」ようにする層です。多層防御の意識で導入します。

Content Security Policy（CSP）

CSPは、ブラウザがどこから読み込んだスクリプトを実行してよいかを制御するレスポンスヘッダです。適切に設計された厳格なCSPであれば、「〈script〉」タグ注入や「javascript：」URLの実行を抑止しやすくなります（「unsafe-inline」を許可すると効果が大きく落ちる点に注意）。

• nonceベース：サーバがランダムなnonceを発行し、「〈script nonce="..."〉」 に一致したスクリプトのみ許可

• strict-dynamic：nonceで許可したスクリプトが読み込む子スクリプトを許可する近代的な書き方

• 「unsafe-inline」 は禁止：これを付けるとCSPの効果が大幅に落ちる

CSPの詳細な設計指針はMDNのXSSの解説やContent Security Policyにまとまっています。

Cookieの属性設計

• HttpOnly：JavaScriptから 「document・cookie」 で読めなくする（Cookie窃取型XSSの被害を減らす）

• Secure：HTTPS通信でのみCookieを送信

• SameSite=Lax or Strict：CSRF対策と併せて設計

多くのWebアプリでは「HttpOnly; Secure」を前提に、SameSiteはLaxを基本線として要件に応じて調整します。クロスサイトでCookieを送る必要があるSSOや埋め込み系のフローでは「SameSite=None; Secure」に切り替えるケースもあります。

Trusted Types API

Trusted Typesは、DOM操作の危険なシンク（「innerHTML」、「document・write」 など）に「文字列を直接渡すことを禁止」できる新しい仕組みです。 「require-trusted-types-for 'script'」 をCSPで指定すると、無害化を通っていない値がシンクに到達した瞬間に例外が発生します。ブラウザ側でDOMベースXSSを構造的に潰せる仕組みで、Google内部でもXSS事故の削減に効果があったと報告されています。

WAFの位置づけ

Cloudflare Managed Rulesなどのマネージド型WAFは、既知のXSSペイロードを一定程度ブロックできますが、DOMベースXSSや難読化された攻撃はすり抜けます。WAFは「発見・遅延・攻撃コスト増加」の効果はあっても、根本対策の代替にはなりません（Cloudflareとは｜CDN・セキュリティ・Workersの特徴と案件動向も参考になります）。

ミニFAQ｜X-XSS-Protectionは今も有効か

Q. 「X-XSS-Protection: 1; mode=block」 を付ければ十分ですか？

このヘッダはChrome・Edgeなど主要ブラウザで既に削除・非推奨扱いになっています。付けても害はありませんが、対策の主軸をここに置くのは危険です。CSPと出力エスケープを本命に据えてください。

フレームワーク別の対策ポイント

主要フレームワークごとに、標準機能の守備範囲と、開発者が意識すべき「例外的に自分で対策が必要なAPI」を整理します。

React

• 自動エスケープ：JSX中の 「{value}」 はテキストノードとしてエスケープされる

• 要注意：「dangerouslySetInnerHTML」、「href」 や 「src」 にユーザー入力を代入するケース、リンク要素の遷移先に 「javascript：」 スキームを許してしまうケース

• 推奨：URLは 「new URL(userInput).protocol」 を検証、HTMLはDOMPurifyでサニタイズ

Vue.js

• 自動エスケープ：「{{ }}」 および 「v-bind」 は基本的にエスケープされる

• 要注意：「v-html」 を使うとき。Vue 3 でも 「v-html」 の内容はサニタイズされない

• 推奨：「v-html」 はサニタイズ済みHTMLだけ渡す運用ルールを徹底する

Next.js／Nuxt

• SSRで生成されるHTMLはフレームワークのエスケープに従うが、「Head」 タグやメタデータ、リダイレクトURLの生成箇所は個別レビュー対象

• 静的生成（SSG）でも、ビルド時にユーザー入力を混ぜる設計にしていないか確認

Laravel Blade／Rails ERB／Django Template

• Bladeの 「{{ $value }}」、ERBの 「〈%= value %〉」、Djangoの 「{{ value }}」 はいずれもHTMLエスケープを自動で行う

• 危険：Bladeの 「{!! !!}」、ERBの 「raw」、Djangoの 「|safe」／「{% autoescape off %}」

• 推奨：レビュー時にこれらの記法をコードベースでgrep検索して洗い出す

Angular

• 標準でコンテキスト認識のサニタイズが行われる（DomSanitizer）

• 要注意：「bypassSecurityTrust*」 系メソッドを呼んでいる箇所

ミニFAQ｜サーバ側フレームワークの自動エスケープを信じてよいか

Q. サーバサイドフレームワークの自動エスケープを信じれば追加対策は不要ですか？

テンプレート内の変数展開は概ね安全ですが、属性値やJavaScriptブロック内での埋め込みまでは自動で守れません。埋め込む場所ごとにエスケープ関数が異なるという原則は、フレームワークを使っていても変わりません。

開発現場での検知方法

XSSは「実装しながら発見する」より「実装後に見つける」ほうが圧倒的に多い脆弱性です。レビュー・静的解析・動的テスト・依存ライブラリの脆弱性チェックを組み合わせて検知します。

コードレビューで拾える典型パターン

• 「innerHTML」への直接代入、「document」の書き込み系API、動的コード実行系（eval・Functionコンストラクタ）

• 「dangerouslySetInnerHTML」、「v-html」、「{!! !!}」、「|safe」、「bypassSecurityTrust*」

• ユーザー入力をリンク属性・遷移先URL・新規ウィンドウのURLに直接渡している箇所

• テンプレート外でHTML文字列を組み立ててから貼り付けているコード

静的解析（SAST）

• ESLint プラグイン：「eslint-plugin-security」、「eslint-plugin-no-unsanitized」

• Semgrep：XSS用ルールが公式リポジトリにあり、CIに組み込みやすい

• GitHub Advanced Security（CodeQL）：クエリの再利用性が高く、モノレポで有効

動的テスト（DAST）

• OWASP ZAP：無償で、パラメータへのペイロード注入・DOMベース検知を自動化

• Burp Suite Professional：手動テストの主流ツール

• リグレッションとして、既知のXSS再発チェックを自動テストに含めるのが実務的

依存ライブラリの脆弱性

• npm audit／pnpm audit、Renovate、Dependabot

• サニタイズライブラリ（DOMPurifyなど）は必ず最新版に追従

• CVEが出た際、影響のあるAPIを実際に使っているかを確認する運用フローが必要

ミニFAQ｜手動テストとツールの優先順位

Q. XSSの検知はツールに任せて大丈夫ですか？

自動化ツールは反射型・簡単な格納型を高速に拾うのが得意ですが、DOMベースXSSや業務ロジックに絡んだXSSはツールの盲点になりやすい種類です。テスト工程の初期はツールを使い、リリース前の重要画面は手動でPoCを試すハイブリッド運用が現実解です。

ケース別｜担当領域ごとの実装ポイント

同じXSSでも、担当ロールによって「まず押さえる対策」が違います。案件アサインの際にどの粒度で発言できるかで単価にも影響する部分です。

フロントエンドエンジニア

• 「innerHTML」 系APIを避け、「textContent」 を優先

• サードパーティスクリプト（広告・SDK）を読み込む前後で信頼境界を意識

• URLパラメータ由来の値を直接DOMに反映しない

• CSPのnonce付与ルールに沿ってスクリプトを書く

バックエンドエンジニア

• テンプレートエンジンの自動エスケープを崩す記法を規約で禁止

• レスポンスヘッダ（CSP、HSTS、X-Content-Type-Options、Cookie属性）を設計

• API側でHTMLを組み立てて返す設計は最小化

• ロール寄りの解説はバックエンドエンジニアとは｜仕事内容・年収・キャリアパスでも触れています

セキュリティエンジニア／SOC

• 既存Webアプリの脆弱性診断（診断報告書のライティングまで含む）

• SIEMログからXSSの試行を検知するルール整備

• 事故発生時のIR（インシデントレスポンス）

• 参考：セキュリティエンジニアとは？年収・将来性・キャリアパス・スキルまで徹底解説、セキュリティアナリストとは｜仕事内容・年収・SOCの役割となり方を解説

情シス・社内Web担当

• WordPress等CMSのプラグインを最小構成に絞る

• 管理者アカウントの二要素認証・IP制限

• 定期的なテーマ・プラグイン更新と脆弱性通知の受信設定

ミニFAQ｜開発者が最初にやるべき1つの対策

Q. XSSの学習を1つに絞るなら、どこから始めるべきですか？

「出力コンテキスト別のエスケープ」をまず理解してください。HTML本文・属性・JavaScript・URLでエスケープ対象が違うという1点を押さえるだけで、フレームワークが自動でやっていることの意味が読めるようになり、危険な記法を避けられます。

フリーランス案件における関係性

XSSに強いエンジニアは、単純なコーダーではなく「レビュー・設計・診断まで踏み込めるロール」として評価されやすい傾向があります。首都圏中心の主要フリーランスエージェント公開案件を見る限り、XSSやセキュアコーディングの経験を条件に含む案件では単価が上振れしやすい傾向があります。

Web開発案件でのXSS対応の位置づけ

• 通常のWeb実装案件でも、SPAリニューアルやリッチテキスト機能を含む募集では、DOMPurifyやCSP設計の経験があると加点されやすい傾向があります

• スクラム内の「セキュリティレビュー担当」ロールとして継続的にアサインされるケースもある

• 官公庁・公共系は特に厳格。官公庁・公共系のフリーランスエンジニア案件｜単価相場・契約形態・セキュリティ要件を徹底解説で契約要件を確認しておくと参画がスムーズ

セキュリティ専業ロールとしての単価感

• 公開案件やエージェント募集要項を見る限り、診断業務・SOC業務のフリーランス案件は、Web開発中位案件より単価が上振れしやすい傾向があります（対象：診断ベンダで手を動かせるレベルの経験3年以上を想定）

• ただし常駐・機密情報の取り扱い制約も強いため、リモート可否・稼働時間を先に確認する必要あり

• 自分がどのゾーンで通用するかの目安は、無料のフリーランスエンジニア単価診断で市場側の反応を確認しておくと判断しやすくなります

資格・スキル証明とセットで見せると通りやすい

• 情報処理安全確保支援士（登録セキスペ）や情報セキュリティマネジメント試験は、書類選考で名刺代わりに機能する

• 実装案件では「レビュー時に指摘した脆弱性の実例」をポートフォリオに近い形で説明できると強い

• 生成AI・LLMアプリ領域ではプロンプトインジェクション対策｜LLMアプリのセキュリティ実装ガイドと併読しておくと守備範囲が広がる

ミニFAQ｜XSS対策の経験を面談でどう伝えるか

Q. XSS対策の経験を面談でアピールするコツはありますか？

「フレームワークの自動エスケープに任せていた」だけでは弱く聞こえます。実際にレビューで見つけた事例、CSPの nonce 運用を設計した経験、DOMPurifyを導入した意思決定など、判断が入ったエピソードを2〜3件持っておくと伝わりやすくなります。

実践チェックリスト

案件参画時／リリース前に確認するとよい観点をまとめました。網羅より優先度が高い項目に絞っています。

• テンプレートエンジンの自動エスケープを迂回する記法（「v-html」、「{!! !!}」、「|safe」、「dangerouslySetInnerHTML」）の使用箇所をコードベースで把握しているか

• 「innerHTML」／「document・write」／「eval」 を直接使っている箇所を確認したか

• ユーザー入力を 「href」／「src」／「onclick」 などの属性に流していないか

• CSPを設定しているか。「unsafe-inline」／「unsafe-eval」 を安易に許可していないか

• セッションCookieに 「HttpOnly; Secure; SameSite」 を付けているか

• リッチテキスト・Markdown→HTMLに変換する箇所でDOMPurify（または同等）を使っているか

• ESLint／Semgrep／CodeQLなど静的解析をCIに組み込んでいるか

• 依存ライブラリの脆弱性通知（Renovate／Dependabot）を受信しているか

• OWASP ZAPかBurp Suiteで反射型XSSのスキャンを最低1回実施したか

• 診断結果に基づいて修正した記録を残しているか（監査対応）

まとめ

XSSは「入力を無害化せずHTMLへ埋め込む」ことで発生し、反射型・格納型・DOMベースの3種類に分かれます。根本対策は出力コンテキスト別のエスケープ、保険対策としてCSP・HttpOnly・Trusted Typesを積み上げる多層防御が基本形です。

• 反射型・格納型・DOMベースの見分け方を、発火経路で覚える

• テンプレートエンジンの自動エスケープは強力だが、迂回記法（「v-html」、「|safe」、「dangerouslySetInnerHTML」）に注意

• CSPは根本対策の代替ではなく、最後の砦として設計する

• コードレビュー・静的解析・DAST・依存脆弱性チェックの4点セットで検知する

• フリーランス案件では「レビューや診断まで踏み込める人材」への需要が根強く、単価も上振れしやすい

セキュリティ設計に強くなりたい方は、SQLインジェクションやプロンプトインジェクションの記事もあわせて読んでおくと、Webの主要脆弱性の全体像がつながります。単価を体系的に上げる考え方はフリーランスエンジニアの単価相場と単価の上げ方で整理しています。

参照した主な一次情報

• IPA 安全なウェブサイトの作り方 クロスサイト・スクリプティング

• IPA 安全なウェブサイトの作り方（全体版）

• MDN Web Docs｜Cross-site scripting (XSS)

• OWASP Cross Site Scripting Prevention Cheat Sheet

• DOMPurify（GitHub）