CSPヘッダーバリデーター
Content-Security-Policyヘッダーの値を貼り付けるだけでディレクティブ・ソース値を一括検証。unsafe-inline等の危険な設定やdefault-src未指定、ディレクティブ名のスペルミスを検出し、ディレクティブごとの許可ソースを視覚的に一覧表示します。
Tips
- CSPは通常HTTPレスポンスヘッダーとして配信しますが、
<meta http-equiv="Content-Security-Policy">タグでも指定できます（ただしreport-uri等一部のディレクティブはmetaタグでは無効です）。 - 本番環境にいきなり適用する前に、Content-Security-Policy-Report-Onlyヘッダーで違反レポートだけを収集し、既存機能への影響範囲を確認してから本適用する運用がおすすめです。
- ワイルドカード（*）や'unsafe-inline'は動作確認を通しやすい反面、CSP本来のXSS対策効果を大きく損ないます。開発中に使った緩い設定は公開前に必ず絞り込みましょう。
- 同じディレクティブを複数回書いても最初の1つしか有効になりません。設定を追加・上書きしたい場合はソースを1本のディレクティブにまとめる必要があります。
- ブラウザのDevToolsコンソールには、CSP違反でブロックされたリソースが「Refused to load...」という赤字メッセージでそのまま表示されるため、デバッグ時にまず確認すべき場所です。
よくある質問
余談ですが ― CSPはなぜ生まれたのか ― 「エスケープの徹底」だけでは守れなかったXSS対策の歴史
CSP（Content Security Policy）は、2004年頃にRobert Hansenが提唱したアイデアを起点に、2008年前後からMozillaのエンジニアであるBrandon Sterneが中心となって仕様化を進め、2012年にW3Cの最初の勧告候補（Level 1）としてまとめられました。当時Webアプリケーションの脆弱性の中でもXSS（クロスサイトスクリプティング）が特に深刻視されており、「出力のエスケープを徹底する」という開発者の注意力だけに頼った対策には限界があるという反省から、ブラウザ側で強制的にスクリプトの実行元を制限する多層防御の仕組みとして設計されました。
CSP Level 2ではnonceやhashによるインラインスクリプトの許可が導入され、'unsafe-inline'を使わずに特定のインラインコードだけを個別に許可できるようになりました。さらにLevel 3で追加された'strict-dynamic'は、信頼済みスクリプトが動的に読み込む子スクリプトを自動的に信頼する仕組みで、大規模サイトでのホワイトリスト保守コストを大きく下げています。
Googleは自社の大規模サービス群にnonceベースの厳格なCSPを導入する取り組みを継続的に行っており、その知見から「ホスト名の許可リスト方式のCSPは迂回されやすく、nonce・hashベースの方が実効性が高い」という研究結果を公表しています。この知見は現在のCSP設計のベストプラクティスとして広く参照されており、単に「危険な値を禁止する」だけでなく「そもそもどの方式で許可を組み立てるか」という設計判断が重要であることを示しています。