# XSS対策ガイド｜実装手順・CSP・外注の要点

- 公開日: 2026-08-07
- 監修: 代表取締役 兼 StockSun創業メンバー 板橋 晟星
- URL: https://www.geek-bridge.com/column/xss-prevention-implementation-guide

XSS（クロスサイトスクリプティング）対策の中心は、外部データを出力先に応じて安全に扱うことです。通常表示はエスケープ、HTMLを許可する箇所はサニタイズを行い、CSPと継続テストを組み合わせます。外注時は対象画面、合格基準、改修後の再診断まで見積もりに含めることが重要です。

XSSは、単に「入力欄からHTMLタグを除去する」だけでは防げません。発注者は個々の実装方法を指定するより、どのデータをどこに表示するか、HTML入力を許可するか、どの状態をもって改修完了とするかを開発会社と合意する必要があります。

## XSS対策で発注者が最初に決めること

XSS対策を漏れなく進めるには、実装を始める前に、対象範囲と許可する表現を決めることが先決です。

XSSとは、Webページに意図しないスクリプトを混入させ、閲覧者のブラウザ上で実行させる脆弱性です。Cookieの窃取だけでなく、ログイン中の利用者としてAPIを呼び出す、画面を書き換える、入力内容を外部へ送るといった被害につながる可能性があります。

代表的な種類は次の3つです。

| 種類 | 仕組み | 発生しやすい場所 | 発注時の確認点 |
|---|---|---|---|
| 反射型XSS | URLやフォームの値が、その場でレスポンスへ反映される | 検索結果、エラー画面、絞り込み条件 | URLパラメータやエラーメッセージまで診断対象に含める |
| 格納型XSS | 不正な値がデータベースなどへ保存され、後から表示される | コメント、プロフィール、問い合わせ、管理画面 | 入力画面だけでなく、保存後に表示される全画面を確認する |
| DOM Based XSS | ブラウザ側のJavaScriptが外部データを危険な方法で画面へ挿入する | 管理画面、動的UI、シングルページ型のWebアプリ | サーバーの応答だけでなく、ブラウザ上で生成されたDOMも検査する |

DOMは、ブラウザがHTMLを画面要素として扱うための構造です。サーバーから返されたHTMLに問題がなくても、ブラウザ側の処理によってXSSが発生することがあります。

### 外部入力はフォームだけではない

対策対象にすべき外部データには、次のようなものがあります。

- フォームの自由記述、氏名、ファイル名
- URLのパラメータやURL末尾の識別子
- Cookie、HTTPヘッダー、外部APIの応答
- データベースに保存済みの過去データ
- CSVインポートや他システムから連携されたデータ
- 管理者、取引先、社内担当者が登録する情報
- HTMLやSVG形式でアップロードされるファイル

管理者だけが使う画面も除外できません。一般利用者が登録したデータを管理画面で表示する構成では、管理者の権限で不正な操作を実行される可能性があるためです。

### プレーンテキストとHTML入力を区別する

発注者が要件として決めるべきなのは、「装飾されたHTMLが本当に必要か」です。お知らせや商品説明でも、太字、リンク、箇条書きだけで足りる場合があります。

| 入力方針 | 適した用途 | 主な対策 | 発注者側の判断 |
|---|---|---|---|
| プレーンテキストのみ | 氏名、検索語、短いコメント | 出力時のエスケープ | 原則としてこちらを選ぶ |
| 限定的な装飾を許可 | 記事、商品説明、社内掲示 | 許可リスト方式のサニタイズ | 許可するタグ、属性、リンク形式を決める |
| 任意HTMLを許可 | 特殊なCMSや制作ツール | 強い権限制御、隔離表示、サニタイズ、CSP | 必要性とリスクを個別に検討する |

エスケープとは、記号をスクリプトとしてではなく文字として表示できる形に変換することです。サニタイズとは、HTMLの構造を解析し、危険なタグや属性を除去することです。両者は目的が異なり、一律の文字置換で代用することはできません。

## XSS対策を実装する6つの手順

実装は「入力をすべて禁止する」のではなく、入力元から最終表示先までの経路を調べ、出力先ごとに安全な方法へ置き換える順番で進めます。

### 1. 入力元と表示先のデータフローを洗い出す

最初に、データがどこから入り、どこへ保存され、どの画面や機能で再利用されるかを一覧にします。発注のご相談を受ける開発会社の立場では、診断対象を「入力フォームのある画面」だけに限定してしまい、管理画面、確認画面、プレビュー、検索結果、外部公開ページへの再表示が漏れるケースが少なくありません。

最低限、次の情報を整理します。

- 対象となる画面、API、利用者権限
- 自由入力項目とURL入力項目
- データの保存先と再表示先
- 管理画面、メールのWebプレビュー、帳票プレビューの有無
- 利用しているフロントエンドの枠組みやテンプレート
- HTML編集機能、外部タグ、広告タグ、アクセス解析タグの有無
- アップロード可能なファイル形式と表示方法

対象範囲をRFP（提案依頼書＝開発会社へ要件や条件を伝える文書）にまとめる場合は、[RFPの作り方｜システム開発の依頼準備](https://www.geek-bridge.com/column/system-development-rfp-creation-guide)も参考になります。

### 2. 出力先ごとに安全な表示方法を選ぶ

XSSが成立する条件は、値が挿入される場所によって異なります。HTML本文向けの処理をJavaScriptやURLへ流用しても、安全とは限りません。

| 出力先 | 基本方針 | 特に避けたい実装 |
|---|---|---|
| HTML本文 | フレームワーク標準のテキスト表示と自動エスケープを使う | 文字列をHTMLとして直接挿入する |
| HTML属性 | 標準の属性設定機能を使い、値の種類も検証する | イベント属性を動的に組み立てる |
| URL属性 | URLとして解析し、許可する通信方式と遷移先を確認する | 入力値をそのままリンク先やリダイレクト先にする |
| JavaScript内 | 外部データをコードへ直接埋め込まない | 文字列からプログラムを実行する |
| CSS内 | 原則として外部入力を埋め込まない | 入力値からスタイル文字列を組み立てる |
| HTMLを許可する本文 | 実績のあるサニタイザーを利用する | 正規表現や自作置換だけでタグを除去する |

ReactやVueなどのフレームワークは、通常のテキスト表示を自動的にエスケープします。ただし、HTMLを直接描画する例外機能、外部ライブラリによるDOM操作、危険なURLまで自動的に安全にしてくれるわけではありません。

### 3. HTMLを許可する箇所だけサニタイズする

記事エディタなどでHTMLが必要な場合は、許可リスト方式でタグと属性を限定します。許可リスト方式とは、「危険なものだけを禁止する」のではなく、「業務上必要と確認できたものだけを許可する」考え方です。

発注時には、少なくとも次を仕様として決めます。

- 許可する見出し、段落、太字、リストなどのタグ
- リンクを許可するか、許可するURLの種類
- 画像を許可するか、画像の保存先を限定するか
- style属性やdata属性を許可するか
- サニタイズを登録時と表示時のどちらで行うか
- 元データを保持する場合、誰が閲覧できるか
- サニタイズ用ライブラリをどのように更新するか

サニタイズ済みの内容を後工程で再加工すると、安全性が崩れる場合があります。そのため、サニタイズ後のデータがどの機能を通るかも確認が必要です。既存データに危険なHTMLが保存されている場合は、新規入力への対策だけでなく、過去データの再処理や非公開化も検討します。

### 4. 危険なDOM操作と例外機能を管理する

開発会社には、HTML文字列を直接挿入するAPI、文字列をプログラムとして実行する機能、フレームワークのHTML直接描画機能を洗い出してもらいます。

全面禁止が難しい場合は、次のような例外管理が現実的です。

- 利用箇所と利用理由を一覧化する
- 直前に行うサニタイズ処理を決める
- コードレビューの必須項目にする
- 静的解析で新規追加を検知する
- 担当者だけの判断で例外を増やさない

静的解析とは、プログラムを実行せず、ソースコードから危険な書き方を検出する方法です。検出結果には誤検知も含まれるため、ツール導入だけで完了とせず、開発者による確認が必要です。

### 5. URLとアップロードファイルを別途検証する

URLはHTMLとしてエスケープされていても、危険な通信方式や意図しない外部サイトへの遷移を許す場合があります。文字列の形だけで判断せず、URLとして解析してから、許可する方式やドメインを確認します。

HTMLやSVGなど、ブラウザ上で能動的な動作を含み得るファイルも注意が必要です。業務要件上不要であれば受け付けない、ダウンロード専用にする、アプリ本体とは別の配信元から提供するといった設計を検討します。

### 6. 入力検証を補助策として行う

文字数、数値範囲、列挙値、日付形式などの入力検証は、不正なデータや想定外の値を減らすために有効です。ただし、入力検証だけをXSS対策にはできません。

例えば、氏名欄で必要な記号まで一律に禁止すると、利用者の正当な入力を妨げます。入力時には業務ルールを検証し、表示時には出力先に合った安全処理を行う、という役割分担が必要です。

## CSPによる多層防御とテストの進め方

エスケープやサニタイズを主対策とし、CSP、Cookie属性、静的解析、ブラウザテストを組み合わせることで、見落としの発生確率と影響を下げられます。

### CSPは段階的に導入する

CSP（Content Security Policy＝ブラウザが読み込めるスクリプトなどを制限する仕組み）は、XSSの多層防御として有効です。ただし、実装不備そのものを修正する機能ではありません。

CSPの検討項目は次のとおりです。

| 項目 | 確認内容 |
|---|---|
| スクリプト | 自社配信、外部タグ、決済、分析ツールなど必要な配信元を限定する |
| インライン処理 | 可能な限り廃止し、必要な場合はnonceやハッシュを検討する |
| オブジェクト | 業務上不要であれば読み込みを禁止する |
| base要素 | 意図しないURL基準の変更を防ぐ |
| iframe埋め込み | 外部サイトからの画面埋め込み可否を制御する |
| 違反レポート | 通知先、保存期間、個人情報を含む可能性を確認する |

nonceは、正規のスクリプトだけを識別するためにレスポンスごとに生成する予測困難な値です。固定値を使い回す運用では十分な効果を得られません。また、安易にインラインスクリプト全体を許可したり、広いワイルドカードを指定したりすると、CSPの効果が弱くなります。

既存サービスへCSPを追加すると、決済、チャット、アクセス解析などの正規機能を止める可能性があります。最初はReport-Only（＝違反を記録するだけで遮断しない状態）で利用状況を確認し、不要な依存先を整理してから強制モードへ移行する進め方が現実的です。Report-Onlyのまま放置しないよう、移行条件と期限も決めます。

### Cookie属性は被害軽減策として設定する

認証用Cookieには、一般に次の属性を検討します。

| 属性 | 役割 | 限界 |
|---|---|---|
| HttpOnly | JavaScriptからCookieを直接読み取りにくくする | ログイン中のブラウザから正規APIを操作される可能性は残る |
| Secure | HTTPS通信時だけCookieを送信する | XSS自体を修正するものではない |
| SameSite | 他サイトを起点とするCookie送信を制御する | 同一サイト内で成立するXSSは防げない |

WAF（Web Application Firewall＝不審な通信を検知・遮断する仕組み）も補助策です。攻撃パターンを一定範囲で遮断できますが、ブラウザ側で発生するDOM Based XSSや、業務上正当な入力に見える攻撃を完全には防げません。

### 自動テストと手動確認を組み合わせる

診断は、代表的な攻撃文字列を入力して終わりではありません。データの保存、再表示、権限、ブラウザ上で生成された要素まで確認します。

推奨する検証の流れは次のとおりです。

1. 入力元、保存先、表示先、利用者権限を一覧化する
2. HTML本文、属性、URL、JavaScriptなど出力先を分類する
3. ソースコードの静的解析とレビューを行う
4. ブラウザ上で画面操作を再現する自動テストを実施する
5. DASTと手動診断で実際の挙動を確認する
6. 改修後に同じ経路を再診断し、周辺機能の回帰テストを行う

DASTとは、稼働中のWebアプリへ外部から通信し、脆弱性を検査する方法です。自動スキャナーは広い範囲を反復確認するのに向きますが、認証後の複雑な操作や特殊な画面状態を見落とすことがあります。そのため、重要機能ではソースコードのレビューと手動診断を併用します。

テスト環境では、個人情報や本番認証情報を原則として使わず、診断用アカウントとデータを準備します。本番環境を検査する場合は、対象日時、負荷、禁止操作、障害時の連絡先、取得データの扱いについて事前承認が必要です。

## XSS対策を外注する費用・期間と見積もりの見方

XSS対策の費用は、見つかった箇所の数よりも、画面数、権限数、古い実装の量、HTML編集機能、テスト範囲によって変わります。診断費と改修費を分けて比較すると、見積もりの違いを把握しやすくなります。

### 費用と期間の一般的な目安

以下は既存Webアプリの調査・改修を外注する場合の一般的な目安です。対象範囲、品質基準、緊急性、資料やテストの整備状況により大きく変動します。

| 対応規模 | 想定する内容 | 費用の目安 | 期間の目安 |
|---|---|---:|---:|
| 限定的な調査・改修 | 数画面の表示処理、既知の指摘への対応、簡易テスト | 20万〜80万円程度 | 1〜3週間程度 |
| 中規模の横断改修 | 複数権限・複数画面、危険APIの調査、回帰テスト、CSP試行 | 80万〜300万円程度 | 1〜2か月程度 |
| 大規模・レガシー環境 | 多数の画面、独自テンプレート、過去データ、外部タグ、段階リリース | 300万〜1,000万円以上 | 2〜6か月以上 |
| 第三者による脆弱性診断 | 認証後画面を含むWeb診断、報告書、再診断 | 50万〜200万円以上 | 2〜6週間程度 |

緊急の脆弱性対応では、まず該当機能の停止、入力制限、表示方法の変更などで影響を抑え、その後に恒久改修を行うことがあります。応急処置と恒久対策を同じものとして扱わず、それぞれの完了条件を明確にしてください。

既存システムの改修見積もり全般については、[システム改修の費用相場｜見積もりと外注の注意点](https://www.geek-bridge.com/column/system-modification-cost-guide)でも詳しく解説しています。

### 見積もりに含めるべき項目

「XSS対応一式」だけの見積もりでは、対象範囲や再診断の有無を比較できません。次の項目が分かれているか確認します。

- 対象画面、API、権限、ドメイン
- 入力元と出力先の調査
- 危険なDOM操作や例外機能のコード調査
- エスケープ、サニタイズ、URL検証の改修
- 過去に保存されたデータへの対応
- CSPの調査、Report-Only、強制モードへの移行
- 静的解析、自動テスト、手動テスト
- 改修後の再診断と回帰テスト
- 本番反映、監視、障害時の切り戻し
- 報告書、設定一覧、残存リスク、運用手順
- 対応後の保証期間と追加費用の条件

調査前には影響範囲を確定できないこともあります。その場合は、短期間の調査を先に契約し、結果を踏まえて改修費を見積もる二段階方式が適しています。最初から固定金額を優先すると、調査不足や過度な予備費につながる場合があります。

### 開発会社・診断会社の見極めポイント

XSS対応を依頼する会社には、製品名や診断ツール名だけでなく、どのように原因と再発防止を説明するかを確認します。

**相談時のチェックリスト**

- XSSの発生箇所を入力元と表示先の経路で説明できる
- HTML本文、属性、URL、DOMなど出力先の違いを区別している
- フレームワーク任せにせず、例外機能や外部ライブラリも確認する
- 自動スキャンだけでなく、手動確認の範囲を提示する
- 診断結果の重要度と、実際の成立条件を説明する
- 修正案だけでなく、テスト方法と再発防止策を提示する
- CSPを一度に強制せず、既存機能への影響を確認する
- 本番環境の検査ルールと取得データの管理方針がある
- 改修後の再診断と残存リスクを報告する
- ライブラリ更新や新機能追加後の運用まで提案できる

診断会社と改修会社を分けると第三者性を確保しやすい一方、調整コストが増えます。同じ会社へ依頼する場合は、診断担当と実装担当のレビューを分ける、改修後だけ第三者へ再診断を依頼するといった方法もあります。

XSSを含むWebアプリの設計レビュー、改修範囲、テスト計画を整理したい場合は、[開発のご相談はこちら](https://www.geek-bridge.com/#contact)からご相談ください。

### 合格基準は「対策済み」より具体的にする

発注者と開発会社の認識を合わせるには、納品時の合格基準を文章で定義します。

合格基準の例は次のとおりです。

- 合意した対象画面と権限について入力・保存・再表示を検査している
- 通常の文字列はHTML要素として解釈されず、文字として表示される
- HTML許可箇所では、合意したタグと属性以外が除去される
- URL入力では、許可されていない通信方式や遷移先が拒否される
- 危険なDOM操作の利用箇所と例外理由が記録されている
- 合意した重要度以上の指摘が解消され、再診断結果が提出される
- CSPの現在の適用状態、例外、強制モードへの移行計画が示される
- 修正によって表示崩れや既存機能の停止が起きていない

「脆弱性が一件もないこと」を無条件に保証させるより、対象範囲、検査方法、重要度、再診断、未対応事項を明確にするほうが、実務上の品質を管理しやすくなります。

## まとめ

- XSS対策の中心は、出力先に応じたエスケープと安全な表示方法の採用です
- HTMLが不要な項目はプレーンテキストとし、必要な箇所だけ許可リスト方式でサニタイズします
- フォームだけでなく、URL、API、保存済みデータ、管理画面、アップロードファイルも対象です
- ReactやVueなどの自動エスケープだけに依存せず、HTML直接描画、DOM操作、URLを確認します
- CSP、Cookie属性、WAFは多層防御であり、実装上のXSS対策の代替ではありません
- 自動スキャン、コードレビュー、ブラウザテスト、手動診断、改修後の再診断を組み合わせます
- 外注時は対象範囲、調査、改修、CSP、回帰テスト、再診断を分けて見積もります
- 納品条件には、対象画面、権限、検査方法、解消すべき重要度、残存リスクを明記します

## よくある質問

### 入力時にHTMLタグを削除すればXSSを防げますか？

いいえ。XSSはHTML本文、属性、URL、JavaScript、DOMなど、値が出力される場所によって成立条件が異なります。入力検証は補助策とし、最終的な表示時に出力先に合ったエスケープやサニタイズを行う必要があります。

### ReactやVueを使えばXSS対策は不要ですか？

不要にはなりません。通常のテキスト表示は自動的にエスケープされますが、HTMLを直接描画する例外機能、外部ライブラリによるDOM操作、危険なURL、保存済みHTMLは個別に確認する必要があります。

### CSPを設定すればXSS脆弱性を解消できますか？

CSPは、スクリプトの読み込み元や実行方法を制限して被害を抑える多層防御です。設定の例外や許可済みスクリプトの悪用もあり得るため、エスケープ、サニタイズ、安全なDOM操作の代わりにはなりません。

### XSS対策の外注費用と期間はどの程度ですか？

限定的な調査・改修は20万〜80万円、1〜3週間程度が一般的な目安です。複数画面の横断改修やCSP導入は80万〜300万円、1〜2か月程度、大規模な既存システムでは300万円以上、2か月以上になることがあります。画面数、権限、過去データ、再診断の範囲によって変動します。