flawopen.com/XSS/CSP とエスケープ
CSP と出力エスケープ：XSS 対策には両方必要？
コンテキストに応じた出力エンコードは、未信頼値を実行可能なマークアップではなくデータとしてページに配置します。Content Security Policy（CSP）は二つ目の防御です。実行できるスクリプトや接続先を確認する門番のように、エンコード漏れがあれば一部の注入動作をブロックできます。漏れ自体は修正せず、緩いポリシーではスクリプトを止められない場合があります。
それぞれの対策が担う役割
データが出力コンテキストに入る時点でエンコードします。HTML テキスト、引用符付き属性、JavaScript、CSS、URL の各要素は解析規則が異なるため、正確なコンテキストに合うエンコーダーが必要です。フレームワークのテンプレートや安全な DOM sink を優先し、inline script やイベント属性などの実行コンテキストに未信頼値を入れないでください。これが XSS の主な予防策です。
適用中の Content-Security-Policy は inline script、スクリプトの配信元、connect-src などの接続先を制限できます。エンコード漏れがあっても、適切なポリシーが特定のスクリプトや接続を止める場合があります。効果はポリシーとブラウザーに依存し、すべての payload、情報流出、script gadget を阻止する保証はありません。注入の欠陥自体は残ります。
CSP が出力エンコードの代わりにならない理由
緩い、または誤設定されたポリシーでは注入が実行される可能性があります。'unsafe-inline' の許可は inline script への保護を弱め、広すぎるホスト許可リストはスクリプトを配信できる endpoint を許可することがあります。CSP の各ディレクティブは役割が異なります。script-src を制限しても、通信先を絞るには connect-src の設定が必要な場合があります。Content-Security-Policy-Report-Only は違反を報告しますがブロックしません。出力エンコードで修正し、CSP は多層防御として使ってください。
よくある質問
必要なスクリプトを洗い出し、'unsafe-inline' と 'unsafe-eval' を避けた nonce または hash ベースのポリシーをテストします。まず Content-Security-Policy-Report-Only で互換性の問題を検出します。これはポリシーを強制しません。レポートを確認して必要な依存関係を調整し、次に適用モードの Content-Security-Policy を配信します。導入中もコンテキストに応じたエンコードを続けてください。