Content-Security-Policy

Content-Security-Policy: <policy-directive>; <policy-directive>

ここで、 <policy-directive> は <directive> <value> の形であり、内部に区切り文字はありません。

フェッチディレクティブは、特定のリソース種別を読み込むことができる場所を制御します。

child-src

ウェブワーカーと、<frame> や <iframe> のような要素によって読み込まれる入れ子の閲覧コンテキストのための有効なソースを定義します。

警告: 入れ子になった閲覧コンテキストやワーカーを制御するには、 child-src の代わりに、それぞれ frame-src および worker-src を使用してください。

connect-src

スクリプトインターフェイスによって読み込まれる URL を制限します。

default-src

別の フェッチディレクティブに対する代替として提供します。

fenced-frame-src Experimental

<fencedframe> 要素に読み込む入れ子になった閲覧コンテキストの有効なソースを指定します。

font-src

@font-face によって読み込まれるフォントのための有効なソースを指定します。

frame-src

<frame> や <iframe> のような要素によって読み込まれた入れ子のコンテンツの閲覧のための有効なソースを指定します。

img-src

画像やファビコンのための有効なソースを定義します。

manifest-src

アプリケーションのマニフェストファイルのための有効なソースを指定します。

media-src

<audio>、<video>、<track> 要素によって読み込むメディアのための有効なソースを指定します。

object-src

<object> や <embed> 要素のための有効なソースを指定します。

メモ: object-src で制御される要素は、おそらく古い HTML 要素に該当すると見なされ、標準化された新しい機能が利用できません（セキュリティ属性の sandbox や <iframe> の allow など）。従って、このフェッチディレクティブで制限を掛けることが推奨されます （例えば、可能であれば object-src 'none' を設定するなど）。

prefetch-src 非推奨 Non-standard

事前にフェッチされるか描画される有効なソースを指定します。

script-src

JavaScript および WebAssembly のための有効なソースを指定します。

script-src-elem

JavaScript の <script> 要素のための有効なソースを指定します。

script-src-attr

JavaScript のインラインイベントハンドラーのための有効なソースを指定します。

style-src

スタイルシートのための有効なソースを指定します。

style-src-elem

スタイルシートの <style> および <link> 要素に rel="stylesheet" がついたものののための有効なソースを指定します。

style-src-attr

個々の DOM 要素に適用されるインラインスタイルの有効なソースを指定します。

worker-src

Worker、SharedWorker、ServiceWorker スクリプトのための有効なソースを指定します。

文書ディレクティブは、ポリシーが適用される文書またはワーカー環境のプロパティを管理します。

base-uri

文書の <base> 要素で使用される URL を制限します。

sandbox

<iframe> と sandbox 属性に類似した要求リソースに対してサンドボックスを有効にします。

ナビゲーションディレクティブは、例えばユーザーが移動する場所やフォームを送信する場所を管理します。

form-action

指定のコンテキストからフォームの送信先として使用される URL を制限します。

frame-ancestors

<frame>、<iframe>、<object>、<embed> によってページに埋め込まれた有効な親を指定します。

報告ディレクティブは CSP 違反の報告過程を制御します。 Content-Security-Policy-Report-Only ヘッダーも参照してください。

report-uri 非推奨

ユーザーエージェントにコンテンツセキュリティポリシーの違反を報告するよう指示します。これらの違反の報告は、 JSON 文書を HTTP の POST リクエストで指定された URI に送信することで行われます。

警告: report-to ディレクティブは非推奨の report-uri ディレクティブを置き換えることを意図していますが、 report-to はまだ多くのブラウザーが対応していません。そのため、ブラウザーで report-to の対応が行われるまでは、現在のブラウザーとの互換性のため、 report-uri と report-to の両方を指定することができます。

http

Content-Security-Policy: …; report-uri https://endpoint.example.com; report-to groupname

report-to に対応しているブラウザーでは、 report-uri ディレクティブは無視されます。

report-to

CSP 違反情報を送信するための報告エンドポイントまたはエンドポイントグループを識別するトークンをブラウザーに提供します。 トークンが表すエンドポイントは、他にも Reporting-Endpoints などの HTTP ヘッダーでで指定されている場合があります。

require-trusted-types-for Experimental

DOM XSS インジェクションシンクで Trusted Types を強制します。

trusted-types Experimental

Trusted Types ポリシーのホワイトリストを指定するために使用します (Trusted Types は、アプリケーションが DOM XSS インジェクションシンクをロックダウンして、文字列の代わりにスプーフィング不可能な型付きの値のみを受け入れるようにします)。

upgrade-insecure-requests

安全でない URL (HTTP で提供されているもの) をすべて安全な URL (HTTPS で提供されているもの) に置き換えたかのように扱うようにユーザーエージェントに指示します。このディレクティブは、書き換えが必要な安全でない古い URL が大量にあるウェブサイトを対象としています。

block-all-mixed-content 非推奨

ページが HTTPS を使用して読み込まれた際に、 HTTP を使用して資産を読み込むことを防止します。

許可さ れている値の概要を以下に示します。 詳細な参照は、CSP ソース値 および各ディレクティブのドキュメントを参照してください。

'none'

すべてのリソースの読み込みを許可しません。

'self'

現在のオリジンからのみリソースの読み込みを許可します。

'strict-dynamic'

ページ内のスクリプトに付随する nonce やハッシュによって与えられた信頼は、それが読み込むスクリプトに拡張されます。

'report-sample'

違反したコードのサンプルを違反レポートに含めて記載することを要求する。

'inline-speculation-rules'

スクリプトに投機ルールを含めることができます（<script type="speculationrules"> も参照）。

'unsafe-inline'

インラインリソースの使用を許可します。

'unsafe-eval'

eval や setTimeout()、window.execScript Non-standard のような動的コード評価の使用を許可します。

'unsafe-hashes'

特定のインラインイベントハンドラーを有効にすることができます。

'wasm-unsafe-eval'

WebAssembly モジュールを読み込んで実行する際に、'unsafe-eval' による安全ではない JavaScript の実行を許可する必要がなくなります。 単一引用符は必須です。

• Host

  • 指定されたホストからのリソースの読み込みのみを許可します。オプションでスキーム、ポート番号、パスを指定することができます。例えば、 example.com, *.example.com, https://*.example.com:12/path/to/file.js などです。
  • CSP 内の / で終わるパス部分は、その接頭辞であるすべてのパスに一致します。例えば、example.com/api/ は example.com/api/users/new のような URL に一致します。
  • CSP の他のパス属性の部分は正確に照合されます。例えば、example.com/file.js は http://example.com/file.js と https://example.com/file.js には一致しますが、https://example.com/file.js/file2.js に一致するわけではありません。

• Scheme

  • 特定のスキームによるリソースの読み込みのみを許可します。常に ":" で終える必要があります。例: https:, http:, data: など

'nonce-*'

スクリプトを許可するための暗号化された (一度しか使われない) ノンスです。サーバーは、ポリシーを送信するたびに、一意のノンス値を生成する必要があります。リソースのポリシーを迂回することは容易ではないため、推測されないノンスを提供することが重要です。これは script の nonce 属性と組み合わせて使用します。例えば、 nonce-DhcnhD3khTMePgXwdayK9BsMqXjhguVV

'sha*-*'

sha256、sha384、sha512 のいずれかです。その後にダッシュと sha* の値が続きます。例: sha256-jzgBGA4UWFFmpOBq0JpdsySukE1FrEN5bUpoK8Z29fY=

ワーカーは、一般的に文書 (もしくは親ワーカー) のコンテンツセキュリティポリシーによって管理されません。ワーカーに対してコンテンツセキュリティポリシーを指定するには、ワーカースクリプト自身が要求したリクエストに対して Content-Security-Policy レスポンスヘッダーを設定して下さい。

ワーカースクリプトのオリジンがグローバルで一意の識別子の場合 (例えば、URL がデータやブロブのスキーマの場合) は例外です。この場合、ワーカーは文書もしくは作成元のワーカーのコンテンツセキュリティポリシーを継承します。

CSP では、Content-Security-Policy ヘッダー、Content-Security-Policy-Report-Only ヘッダーや <meta> 要素を経由したものを含む、リソースに対して複数のポリシーを指定することができます。

以下の例のように、 Content-Security-Policy ヘッダーを複数回使うことができます。ここでは connect-src ディレクティブに特に注意してください。 2 つ目のポリシーでは接続を許可しているにもかかわらず、 1 つ目のポリシーには connect-src 'none' が含まれています。追加のポリシーを追加しても、保護されたリソースの機能がさらに制限することができるだけで、接続は許可されず、最も厳密なポリシーとして connect-src 'none' が強制されます。

Content-Security-Policy: default-src 'self' http://example.com;
                          connect-src 'none';
Content-Security-Policy: connect-src http://example.com/;
                          script-src http://example.com/

例: 安全でないインラインの eval を無効にし、http 経由でのリソース (画像、フォント、スクリプトなど) 読み込みを許可します。

<meta http-equiv="Content-Security-Policy" content="default-src https:" />

例: 修正のためにインラインコードを多用している既存のサイトで、https 経由でのみ読み込まれるリソースを明確にし、プラグインを無効にします。

Content-Security-Policy: default-src https: 'unsafe-eval' 'unsafe-inline'; object-src 'none'

例: 上記のポリシーを実装せず、代わりに、発生するであろう違反を報告します。

Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-violation-report-endpoint/

その他の例は、Content Security Policy (CSP) の実装 を参照して下さい。

• Content-Security-Policy-Report-Only
• コンテンツセキュリティポリシーを学ぶ
• WebExtension のコンテンツセキュリティ
• Adopting a strict policy
• CSP Evaluator - コンテンツセキュリティポリシーを評価する