読み込み元を絞る厳格なCSP作成

開発者や管理者が、ページで読み込める資源を制限する方針を新設または強化したい場面に向いています。

許可したい取得元を選びながら厳格なContent-Security-Policyを構成し、テスト可能な指示文として安全にコピーして、導入前の検証へ進めます。

使い方

  1. 最初の行でデフォルトソースから始めます。これは個別に列挙しないすべてのリソースタイプのフォールバックとして機能します。
  2. 次の行で、スクリプトの配信を許可するオリジンを列挙し、スペースで区切って順に書きます。
  3. 3行目は接続ソース用です。つまり、ページがネットワークリクエストで到達できるオリジンです。
  4. ポリシーを構築します。ディレクティブ一式が結果エリアに表示され、上から下へ読めるようになります。
  5. ポリシーをヘッダーまたは設定ファイルにコピーし、適用する前にレポート専用モードで展開します。

使用例

サンプルでは、メインドメインをデフォルトソースとして許可し、スクリプト用にそのドメインと配信用ドメインを繰り返し、接続用に別のドメインを保持しています。構築後、結果エリアに複数の重複するディレクティブではなく、1つの一貫したポリシーが入っていることを確認してください。

入力

https://example.com
https://example.com https://cdn.example.com
https://api.example.com

出力

default-src https://example.com; script-src https://example.com https://cdn.example.com; connect-src https://api.example.com; object-src 'none'; base-uri 'self'; frame-ancestors 'none'

制限と形式

処理の場所

ポリシーはブラウザー内で組み立てられます。入力したドメインはデバイス上に残り、何も送信されず、タブを閉じた後にコピーも残りません。そのため、まず内部設定を下書きするのに実用的です。

よくある質問

デフォルトソースとスクリプトソースの違いは何ですか?

デフォルトソースは、個別に列挙していないリソースタイプのフォールバックであり、スクリプトソースは実行可能コードだけを管理します。したがって、スクリプトソースとして許可されたドメインが、スタイル、画像、接続にも自動的に許可されるわけではありません。

ポリシーを公開した後、ページが壊れるのはなぜですか?

通常は正当なオリジンが不足しています。外部スタイルシート、フォント、埋め込みフレーム、分析サービスなどです。ページが実際に呼び出すすべてのリソースを列挙し、不足しているドメインを追加してポリシーを再構築し、もう一度公開してください。

同じポリシーを複数のサイトで再利用できますか?

文言は簡単に流用できますが、各サイトはそれぞれのリソースを読み込みます。テキストを出発点として扱い、各プロジェクトに合わせてドメインを調整し、ページが依存しているものをブロックしないようにしてください。

同じカテゴリのツール