Content-Security-Policy

HTTP の Content-Security-Policy レスポンスヘッダーは、ウェブサイト管理者が、あるページにユーザーエージェントが読み込みを許可されたリソースを管理できるようにします。いくつかの例外を除いて、大半のポリシーにはサーバーオリジンとスクリプトエンドポイントの指定を含んでいます。これはクロスサイトスクリプティング攻撃 (XSS) を防ぐのに役立ちます。

より詳細な情報は、 Content Security Policy (CSP) の入門記事を参照してください。

構文

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

ここで、 <policy-directive> は次の要素で構成されます: <directive> <value> 内部の句読点なし。

ディレクティブ

フェッチディレクティブ

フェッチディレクティブは、特定のリソース種別がロードされうる場所を制御します。

Content Security Policy フェッチディレクティブの一覧

child-src

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

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

connect-src

script インターフェースによってロードされる URL を制限します。

default-src

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

font-src

@font-face によってロードされるフォントに対する有効なソースを指定します。

frame-src

<frame> や <iframe> のような要素によってロードされる入れ子状のコンテンツの閲覧に対する有効なソースを指定します。

img-src

画像や favicon に対する有効なソースを定義します。

manifest-src

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

media-src

<audio>、<video> や <track> 要素によってロードするメディアに対する有効なソースを指定します。

object-src

<object>、 <embed> や <applet> 要素に対する有効なソースを指定します。

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

prefetch-src

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

script-src

JavaScript に対する有効なソースを指定します。

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 スクリプトに対する有効なソースを指定します。

文書ディレクティブ

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

Content Security Policy 文書ディレクティブの一覧

base-uri

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

plugin-types

ロードされるリソースのタイプを限定することで、文書に埋め込まれるプラグインの組を制限します。

sandbox

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

ナビゲーションディレクティブ

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

Content Security Policy ナビゲーションディレクティブの一覧

form-action

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

frame-ancestors

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

navigate-to

<form> (form-action が指定されていない場合), <a>, window.location, window.open, など、あらゆる方法で文書からナビゲーションを行うことができる URL を制限します。

報告ディレクティブ

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

Content Security Policy 報告ディレクティブの一覧

report-uri

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

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

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

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

report-to

SecurityPolicyViolationEvent を発生させます。

その他のディレクティブ

block-all-mixed-content

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

referrer

ページから離れる際の Referer ヘッダー内の情報を指定するために使用されていました。代わりに Referrer-Policy ヘッダーを使用してください。

require-sri-for

ページ上のスクリプトやスタイルに SRI の使用を要求します。

require-trusted-types-for

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

trusted-types

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

upgrade-insecure-requests

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

Worker 内の CSP

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

Worker スクリプトのオリジンがグローバルで一意の識別子の場合、(例えば、URL がデータやブロブのスキーマの場合)、例外に当たります。この場合、Worker は文書もしくは作成元の Worker の Content Security Policy を継承します。

複数の CSP

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/

例

例: 安全でない inline/eval を無効にし、https 経由でのリソース (画像、フォント、スクリプトなど) のロードを許します。

// ヘッダー
Content-Security-Policy: default-src https:

// メタタグ
<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/

その他の例は、 Mozilla Web Security Guidelines を参照して下さい。

仕様書

ブラウザーの互換性

このページの互換性一覧表は構造化データから生成されています。データに協力していただけるのであれば、 https://github.com/mdn/browser-compat-data をチェックアウトしてプルリクエストを送信してください。

関連情報

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