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

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

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

• XSS対策で発注者が最初に決めること
  • 外部入力はフォームだけではない
  • プレーンテキストとHTML入力を区別する
• XSS対策を実装する6つの手順
  • 1. 入力元と表示先のデータフローを洗い出す
  • 2. 出力先ごとに安全な表示方法を選ぶ
  • 3. HTMLを許可する箇所だけサニタイズする
  • 4. 危険なDOM操作と例外機能を管理する
  • 5. URLとアップロードファイルを別途検証する
  • 6. 入力検証を補助策として行う
• CSPによる多層防御とテストの進め方
  • CSPは段階的に導入する
  • Cookie属性は被害軽減策として設定する
  • 自動テストと手動確認を組み合わせる
• XSS対策を外注する費用・期間と見積もりの見方
  • 費用と期間の一般的な目安
  • 見積もりに含めるべき項目
  • 開発会社・診断会社の見極めポイント
  • 合格基準は「対策済み」より具体的にする
• まとめ
• よくある質問
  • 入力時にHTMLタグを削除すればXSSを防げますか？
  • ReactやVueを使えばXSS対策は不要ですか？
  • CSPを設定すればXSS脆弱性を解消できますか？
  • XSS対策の外注費用と期間はどの程度ですか？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

対象範囲をRFP（提案依頼書＝開発会社へ要件や条件を伝える文書）にまとめる場合は、RFPの作り方｜システム開発の依頼準備も参考になります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

既存システムの改修見積もり全般については、システム改修の費用相場｜見積もりと外注の注意点でも詳しく解説しています。

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

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

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

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

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

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

相談時のチェックリスト

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

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

XSSを含むWebアプリの設計レビュー、改修範囲、テスト計画を整理したい場合は、開発のご相談はこちらからご相談ください。

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

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

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

• 合意した対象画面と権限について入力・保存・再表示を検査している
• 通常の文字列は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か月以上になることがあります。画面数、権限、過去データ、再診断の範囲によって変動します。