Content-Security-Policy (CSP)

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

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

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

child-src

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

prefetch-src 非推奨; 非標準

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

script-src

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

script-src-elem および script-src-attr の代替となります。

script-src-elem

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

script-src-attr

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

style-src

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

style-src-elem および style-src-attr の代替となります。

style-src-elem

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

style-src-attr

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

worker-src

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

すべてのフェッチディレクティブには、単一の値として'none' を指定することができ、これは特定のリソースタイプを完全にブロックすることを意味します。または、1つ以上のソース表現値として指定することができ、これはそのリソースタイプの有効なソースを意味します。詳細は、フェッチディレクティブの構文を参照してください。

代替

一部のフェッチディレクティブは、他にもっと細かいディレクティブの代替として機能します。これは、もっと細かいディレクティブが指定されていない場合、代替ディレクティブがそのリソースタイプに対してポリシーを提供して使用されるということを意味しています。

• default-src は他のすべてのフェッチディレクティブの代替となります。
• script-src は script-src-attr および script-src-elem の代替となります。
• style-src は style-src-attr および style-src-elem の代替となります。
• child-src は frame-src および worker-src の代替となります。

例えば、次のようになります。

• img-src が省略され、default-src があった場合、default-src で定義されたポリシーが画像に適用されます。
• script-src-elem が省略され、 script-src があった場合、 script-src で定義されたポリシーが <script> 要素に適用されます。
• script-src-elem と script-src がともに省略された場合、 default-src で定義されたポリシーが <script> 要素に適用されます。

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

base-uri

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

sandbox

<iframe> と sandbox 属性に類似した、リクエストされあtリソースに対してサンドボックスを有効にします。

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

form-action

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

frame-ancestors

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

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

report-to

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

警告: このディレクティブは report-uri を置き換えることを意図しています。 report-to に対応したブラウザーでは、 report-uri ディレクティブは無視されます。 ただし、report-to が広く対応されるようになるまでは、次のようにどちらのヘッダーも指定してください（ここで、endpoint_name は別個に提供されたエンドポイントの名前です）。

http

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

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 を使用して資産を読み込むことを防止します。

report-uri 非推奨;

ユーザーエージェントにコンテンツセキュリティポリシーの違反を報告するよう指示します。 これは report-to ディレクティブに置き換えられました。

すべてのフェッチディレクティブは、次のどちらかを指定します。

• 単一の値 'none' は、特定のリソース型を完全にブロックすべきであることを示します。
• 1 つ以上のソース式値は、そのリソース型に対する有効なソースを示します。

各ソース式は下記に列挙するいずれかの形式を取ります。 すべての形式がすべてのフェッチディレクティブに適用できるわけではないことに注意してください。適用できる形式については、各フェッチディレクティブのドキュメントを参照してください。

<host-source> および <scheme-source> 形式は引用符なしで、また、他にもすべて引用符で囲む必要があります。

この値は、文字列 nonce- に続いて base64 エンコードされた文字列から成ります。この文字列は、サーバーが HTTP レスポンスごとに生成するランダムな値です。例を示します。

'nonce-416d1177-4d12-4e3b-b7c9-f6c409789fb8'

サーバーは、同じ値をこの文書から読み込もうとする <script> または <style> の nonce 属性の値として含めることができます。

ブラウザーは CSP ディレクティブの値と要素属性の値を照合し、一致した場合のみリソースを読み込みます。

ディレクティブがノンスと unsafe-inline を持っている場合、ブラウザーは unsafe-inline を無視します。

さらなる使用例の情報については、 CSP ガイドのノンスを参照してください。

この値は、ハッシュアルゴリズムを識別する文字列に続いて、 base64 エンコードされた文字列から成り、ハッシュ値を表します。

• ハッシュアルゴリズム識別子は、sha256、sha384、sha512 のいずれかでなければなりません。
• ハッシュ値は、 <script> または <style> リソースの base64 エンコードされたハッシュであり、SHA-256、SHA-384、SHA-512 のいずれかのハッシュ関数を使用して計算されます。

例を示します。

'sha256-cd9827ad...'

ブラウザーが文書を受け取ると、 <script> および <style> 要素のコンテンツをハッシュ化し、その結果を CSP ディレクティブ内のハッシュと照合し、一致した場合のみリソースを読み込みます。

要素が（例えば src 属性を使用して）外部リソースを読み込んだ場合、その要素には integrity 属性もなければなりません。

ディレクティブにハッシュと unsafe-inline がある場合、ブラウザーは unsafe-inline を無視します。

より詳しい使用方法については、 CSP ガイドのハッシュの項目を参照してください。

リソースの有効なソースであるホストの URL または IP アドレスです。

スキーム、ポート番号、パスはオプションです。

スキームを省略した場合は、文書のオリジンのスキームが使用されます。

スキームが一致する場合、安全なアップグレードが許可されます。例えば：

• http://example.com は https://example.com からのリソースも許可します。
• ws://example.org は wss://example.org からのリソースも許可します。

ワイルドカード ('*') は、サブドメイン、ホストアドレス、ポート番号に使用することができ、それぞれすべての有効な値が有効であることを示します。例を示します。

• http://*.example.com は、 HTTP または HTTPS で、 example.com のどのサブドメインからのリソースも許可します。

/ で終わるパスは、それらが接頭辞である任意のパスと照合します。例を示します。

• example.com/api/ は example.com/api/users/new からのリソースを許可します。

/ で終わらないパスは正確に一致します。例を示します。

• https://example.com/file.js は https://example.com/file.js からのリソースを許可しますが、 https://example.com/file.js/file2.js からは許可しません。

スキーム （https: など）です。コロンは必須です。

安全なアップグレードが許可されています。

• http: は HTTPS を使用して読み込まれたリソースも許可します。
• ws: は WSS を使用して読み込まれたリソースも許可します。

指定された型のリソースは、文書と同じオリジンから読み込まれたもののみです。

安全なアップグレードが許可されています。

• この文書が http://example.com から提供され、 CSP が 'self' であれば、 https://example.com からのリソースも許可します。
• この文書が ws://example.com から提供され、 CSP が 'self' であれば、 wss://example.com からのリソースも許可します。

既定では、 CSP に default-src または script-src ディレクティブが含まれている場合、引数を JavaScript として評価する JavaScript の機能は無効になります。これには、eval()、setTimeout() の code 引数、または Function() コンストラクターが含まれます。

この保護を解除するには、 unsafe-eval キーワードを使用することができます。これにより、 JavaScript で文字列を動的に評価できるようになります。

詳しい使い方の情報は、 CSP ガイドの eval() と同様の API を参照してください。

既定では、 CSP に default-src または script-src ディレクティブが含まれている場合、ページは WebAssembly.compileStreaming() などの関数を使用して WebAssembly をコンパイルすることは許可されません。

この保護を解除するには、 wasm-unsafe-eval キーワードを使用することができます。これは、 JavaScript の一般的な評価を可能にしないため、 'unsafe-eval' よりもはるかに安全な代替手段です。

既定では、 CSP に default-src または script-src ディレクティブが含まれている場合、インライン JavaScript の実行は許可されません。これには以下が含まれます。

• インラインの <script> タグ
• インタ印のイベントハンドラー属性
• javascript: URL

同様に、 CSP で default-src または style-src ディレクティブを記載している場合、インライン CSS は読み込まれません。

• インラインの <style> タグ
• style 属性

この保護を解除し、これらのフォームをすべて読み込むことを許可するには、unsafe-inline キーワードを使用することができます。

詳しい使い方の情報は、 CSP ガイドのインライン JavaScript を参照してください。

既定では、 CSP に default-src または script-src ディレクティブが含まれている場合、 onclick やインライン style 属性などのインラインイベントハンドラー属性は実行できません。

'unsafe-hashes' 式は、インラインイベントハンドラーやスタイル属性にハッシュ式を使用することをブラウザーに許可します。例えば、 CSP には次のようなディレクティブが含まれているかもしれません。

script-src 'unsafe-hashes' 'sha256-cd9827ad...'

ハッシュ値がインラインイベントハンドラー属性値または style 属性値のハッシュと一致する場合、そのコードは実行が許可されます。

<button onclick="transferAllMyMoney()">Transfer all my money</button>

既定では、 CSP に default-src または script-src ディレクティブが含まれている場合、インライン JavaScript の実行は許可されません。 'inline-speculation-rules' は、ブラウザーが type 属性が speculationrules であるインライン <script> 要素を読み込むことを許可します。

詳しくは投機ルール API を参照してください。

'strict-dynamic' キーワードは、ノンスまたはハッシュによってスクリプトに付与された信頼を、例えば、 Document.createElement() を使用して新しい <script> タグを作成し、 Node.appendChild() を使用して文書内のタグを挿入するなど、動的に読み込まれたスクリプトにも拡張します。

このキーワードがディレクティブに存在する場合、次のソース式の値はすべて無視されます。

• <host-source>
• <scheme-source>
• 'self'
• 'unsafe-inline'

より詳しい使用に関する情報は、 CSP ガイドの strict-dynamic キーワードを参照してください。

この式がスクリプトやスタイルを制御するディレクティブに含まれ、そのディレクティブがブラウザーにインラインスクリプト、インラインスタイル、またはイベントハンドラー属性をブロックさせる場合、ブラウザーが生成する違反レポートには、ブロックされたリソースの最初の 40 文字を含む sample プロパティが含まれます。

ワーカーは、一般的に文書 (もしくは親ワーカー) のコンテンツセキュリティポリシーによって管理されません。ワーカーに対してコンテンツセキュリティポリシーを指定するには、ワーカースクリプト自身が要求したリクエストに対して 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/

この HTTP ヘッダーは、既定ではリソースの読み込み（画像、フォント、スクリプトなど）を HTTPS 経由のみ許可するように設定します。 unsafe-inline および unsafe-eval ディレクティブが設定されていないため、インラインスクリプトはブロックされます。

Content-Security-Policy: default-src https:

HTML の <meta> 要素を使用しても、同じ制限を適用することができます。

<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 ヘッダーと report-to ディレクティブを使用して、前回と同じ制限を設定します。 この手法は、検査中に違反を報告するために使用しますが、コードの実行をブロックすることはありません。

レポートを送信するエンドポイント (URL)、 HTTP レスポンスヘッダーの Reporting-Endpoints を使用して定義します。

Reporting-Endpoints: csp-endpoint="https://example.com/csp-reports"

CSP ポリシーでは、 report-to ディレクティブを使用して、具体的なエンドポイントが報告先として選択されます。

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

report-uri 非推奨; ディレクティブも上記で指定されていることに注意してください。 report-to はまだ広くブラウザーが対応していないためです。

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

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