CSP ジェネレーター
構文を覚えなくても Content-Security-Policy ヘッダーを作れます。ディレクティブごとにソースを選び、プリセットから始め、弱い部分を確認して、サーバー、meta タグ、_headers ファイル用にコピーしてください。すべてブラウザー内で動作します。
ポリシーを作成
プリセットから始め、各ディレクティブに必要なソースにチェックを入れ、独自のホストを追加します。ポリシーはすぐに更新されます。
ポリシーはブラウザー内で作成されます。選んだり貼り付けたりした内容がサーバーに送られたり、記録・保存されたりすることはありません。
Content-Security-Policy は、ページがスクリプト、スタイル、画像、フォント、フレームをどこから読み込めるかをブラウザーに正確に伝えます。それ以外はすべてブロックされるため、ほとんどのクロスサイトスクリプティングの不具合は侵害ではなくコンソールのエラーで済みます。難点は構文で、引用符やソースが1つ欠けるだけでサイトが壊れます。このジェネレーターはポリシーを代わりに書き、保護を密かに無効にしてしまう設定を指摘します。
主なメリット
よくある用途
使い方
- 1.プリセットを選ぶ。 厳格な基本形 から始め、サイトで使う Google Analytics 4 や Google Fonts などを追加します。今のポリシーを読み込むこともできます。
- 2.各ディレクティブを調整する。 必要なキーワードにチェックを入れ、下の欄に
https://cdn.example.jpのような追加ホストを入力します。 - 3.ポリシーのチェックを読む。 ✗ の項目を修正し、⚠ の項目は判断します。各メッセージに理由が書かれています。
- 4.まずレポートのみで導入する。 レポートのみモード をオンにしてサーバー用のスニペットをコピーし、強制する前に数日間ブラウザーのコンソールを確認します。
特に重要なディレクティブ
default-src で厳しく始め、実際の機能に必要なものだけを開放します。保護の大部分はこの6つの設定が担います。
'unsafe-inline' は避け、インラインコードは nonce かハッシュで許可し、実際に使うスクリプトのホストだけを列挙します。主な機能
- 14 のディレクティブ。それぞれにキーワードと自由入力のホスト
- 厳格な基本形、Google Analytics 4、Google Fonts、YouTube、Stripe のプリセット
- 既存のヘッダーを読み込んで見直し・拡張が可能
- unsafe-inline、unsafe-eval、https:、data:、ワイルドカード、欠けたディレクティブをリアルタイムでチェック
- レポートのみモード、upgrade-insecure-requests、report-uri に対応
- HTTP ヘッダー、meta タグ、Nginx、Apache、_headers ファイル向けに出力
- ブラウザー内で動作し、何もアップロードしません
CSP は第二の防御線です
CSP はインジェクションの不具合をすり抜けられたときの被害を抑えるものであり、出力のエスケープや入力の検証の代わりにはなりません。'unsafe-inline' のスクリプトやあらゆる HTTPS ホストを許可するポリシーは安心感があっても、ほとんど何も防ぎません。ここでの警告こそが本当の作業です。
新しいポリシーは慎重に導入しましょう。まず Report-Only で送り、壊れた部分を直してから強制します。導入後は、当サイトの セキュリティヘッダーチェッカー で、HSTS などと一緒にヘッダーが実際に送信されているか確認できます。セキュリティヘッダーのガイド では、CSP とほかのヘッダーの関係を解説しています。
よくある質問
Content-Security-Policy とは何ですか？⌄
ページがスクリプト、スタイル、画像、フォント、フレームなどのリソースをどこから読み込めるかを列挙する HTTP レスポンスヘッダーです。ブラウザーはそれ以外をすべてブロックします。主な役割はクロスサイトスクリプティングを防ぐことで、攻撃者が script タグを注入しても、ブラウザーは実行を拒否します。
ヘッダーと meta タグのどちらを使うべき？⌄
できる限り HTTP ヘッダーを使ってください。meta タグはほとんどのディレクティブで機能しますが、frame-ancestors、report-uri、レポートのみモードは使えず、タグより後のコンテンツにしか適用されません。ヘッダーを設定できないホスティング向けの代替手段です。
script-src の 'unsafe-inline' はなぜ悪いのですか？⌄
攻撃者が注入したものも含め、あらゆるインラインスクリプトの実行を許してしまうからです。これはまさに CSP が防ぐべきものです。インラインスクリプトが必要なら、レスポンスごとに変わる nonce を付けるか、その SHA-256 ハッシュを許可してください。style-src の 'unsafe-inline' はリスクがずっと低く、許容されることも多いです。
CSP でサイトが壊れませんか？⌄
厳しいポリシーは、最初は解析タグ、フォント、埋め込みなどを何かしらブロックするのが普通です。そのため、まず Content-Security-Policy-Report-Only で送り、コンソールやレポートの送信先を確認し、本当に必要なソースを追加してから強制に切り替えてください。
CSP が有効か確認するには？⌄
ページを開いて開発者ツールでレスポンスヘッダーを確認するか、セキュリティヘッダーチェッカーでドメインを調べます。違反はディレクティブとブロックされた URL とともにコンソールに表示されるので、何を追加すべきかがすぐ分かります。