CSP 生成

ディレクティブとソースにチェックを入れると、このページはレスポンスヘッダーまたは <meta> タグ用の正しい 1 行の Content-Security-Policy を組み立てます — 加えて重要な注意点:どのディレクティブが default-src に決してフォールバックしないか、ハッシュや nonce がいつ unsafe-inline を黙って上書きするか、strict-dynamic が何を無効にするか。内蔵の SHA-256/384/512 ハッシュ生成器がインラインスクリプトとスタイルを 'sha256-…' ソースに変えます。すべてブラウザー内で動作し、何もアップロードされません。
未チェックのディレクティブはポリシーに単に含まれません。チェックしてソース未選択のものは無視されます。'none' は同じ行の他のボックスを打ち消します。追加ソース欄はカンマ区切りリストを受け付けます:ホスト名(cdn.example.com)、スキーム(https:)、引用符ありなしのハッシュと nonce。
ディレクティブ 'self''none''unsafe-inline' 'unsafe-eval''strict-dynamic' data:blob: 追加ソース
この 4 つは default-src にフォールバックしません:省略は「制限なし」を意味するため、完全なポリシーでは明示的に設定します。
ディレクティブ'self''none'追加ソース

スクリプト nonce
report-uri
report-to
まだ何も構築されていません。ソースにチェックを入れてポリシーを構築を押すか、OWASP ベースラインのサンプルを読み込んでください。
<script> と </script> の間(またはスタイルブロック)の正確な内容を貼り付けてください — バイト単位で、前後に改行なし — アルゴリズムを選びます。結果が CSP 3 が期待する 'sha256-…' ソースです。
ハッシュ出力がここに表示されます。
可能な限り meta タグではなくヘッダーとしてデプロイしてください。レスポンスヘッダーが完全な CSP です:frame-ancestors、report-uri、report-to はそこでしか動かず、ヘッダーは HTML の最初のバイトが解析される前に適用されます。meta タグはサーバー設定のない静的ファイル向けのフォールバックです。サイトが実際に送るヘッダーはセキュリティヘッダーチェッカーで確認し、生の応答ブロックはHTTP ヘッダーパーサーで分解してください。
セルフテスト
ビルダーを固定状態に対して再実行します:ソース順序、'none' の相互排他、OWASP ベースライン文字列、nonce とハッシュの引用、base-uri / form-action / frame-ancestors のフォールバックなし注意、nonce かハッシュによる unsafe-inline の上書き、strict-dynamic の注意、Report-Only ヘッダー名、meta タグ除外、独立に計算した SHA ベクトルに対するハッシュ生成器、ネガティブパス。何もどこにも送信されません。
Content Security Policy とは何か?
一文で言うと:CSP とは、サーバーがページとともに送るホワイトリストで、スクリプト・スタイル・画像・接続がどこから来てよいかをブラウザーに正確に伝えます — たとえ攻撃者が HTML を注入できても、注入されたスクリプトのソースはリストにないため読み込みに失敗します。
3 つのディレクティブグループ
グループ例制御対象default-src にフォールバック?
フェッチディレクティブscript-src、style-src、img-src、connect-src、font-src、object-src、frame-src、worker-src、media-src、manifest-src各種コンテンツをどこから読み込めるかはい — 未チェックのディレクティブは default-src を継承
ドキュメントディレクティブbase-uri、form-action、frame-ancestors、sandboxページ自身にできること(埋め込み、フォーム送信先、相対 URL の基準)いいえ — それぞれ明示的に設定する必要
報告とその他report-uri、report-to、upgrade-insecure-requests違反レポートの送り先、レガシー URL の昇格いいえ(フェッチディレクティブではないため)
最も鋭い刃先、各一段落で

'unsafe-inline' とハッシュ・nonce。ディレクティブに nonce または任意のハッシュソースが含まれる場合、CSP 3 は 'unsafe-inline' を無視します — 古いブラウザー向けに残るだけです。だから「安全のため nonce を追加して unsafe-inline を残した」は実際には、現代のブラウザーが nonce を強制することを意味します。生成器はこの組み合わせを警告するので、事故ではなく決断になります。

strict-dynamic は許可リストを無効化します。script-src に strict-dynamic があると、ホストソース、スキーム、'self'、'unsafe-inline'、data: はスクリプトに対してすべて無視され、nonce とハッシュのみが効き、それらが読み込んだスクリプトはさらにスクリプトを読み込めます。ローダースクリプトを実行する現代的な方法です — ただし script-src リストの残りは飾りになります。

meta タグは二級市民。frame-ancestors、report-uri、report-to は <meta http-equiv> では無視されます。生成器はポリシーのどの部分が黙って適用されないかを表示します。

よくある間違い
  • default-src * と長い例外リストから始める。逆にやってください:厳しい default-src 'self' から始め、広げる必要があるディレクティブだけ広げる。狭いポリシーはテスト中に派手に失敗し、広いポリシーは永遠に静かに失敗します。
  • script-src 'unsafe-inline' 'unsafe-eval' を出荷して完了とする。そのポリシーは XSS 攻撃がやりたいことをほぼ何もブロックしません。スクリプトに nonce かハッシュを付け、strict-dynamic を追加し、本番でも report-only を回して回帰を捕捉してください。
  • default-src がすべてをカバーするわけではないことを忘れる。base-uri、form-action、frame-ancestors、sandbox にはフォールバックがありません — 実世界の CSP 導入で最も引用される隙間です。
  • いきなり強制モードでテストする。コレクターつきの Report-Only で 1 週間走らせ、レポートを読んでから強制に切り替えてください。購入フローを壊すポリシーは、ポリシーなしより悪いです。
  • 空白のハッシュの取り扱いを変える。ハッシュはインラインブロックの正確なバイトをカバーします。末尾の改行を削る「親切な」ビルドステップはすべてのハッシュを変えます。ソースからではなく、出荷されるものからハッシュを生成してください。
よくある質問

すべてのディレクティブを列挙すれば default-src は不要?不要ですが、床として残すのは良い衛生です:将来のブラウザーの新しいフェッチディレクティブが「許可」ではなくあなたのベースラインを既定にします。

upgrade-insecure-requests は実際何をする?ページが読み込もうとするすべての http:// URL(画像、スタイル、fetch)を要求前に https:// に書き換えるようブラウザーに指示します。移行ツールであり、最終状態は http:// URL を一切含まないページです。

nonce かハッシュ、どちら?サーバー応答を制御できるなら nonce(応答ごとの乱数値をヘッダーと各 script タグの両方に)。HTML が静的またはキャッシュされるならハッシュ。静的な nonce は決して使わないで — 変わらない nonce は、ひと手間加えただけの unsafe-inline です。

ポリシーを配信したのに違反が届かないのはなぜ?Report-Only になっていないか、report-uri が POST を受け付けるコレクターを指しているか、現代の report-to ディレクティブが必要とする Reporting-Endpoints / Report-To 機構も設定しているか確認してください。

CSP は他の保護を置き換える?いいえ。1 つの層です:出力のエスケープを続け、Cookie は HttpOnly と Secure の後ろに置き、HSTS を維持してください。このサイトのセキュリティヘッダーチェッカーが全体を採点します。