コンテンツ セキュリティ ポリシー

ジョー・メドレー
Joe Medley
Twitter GitHub

ウェブのセキュリティ モデルは、同一オリジン ポリシーに基づいています。https://mybank.com のコードには、https://mybank.com のデータのみへのアクセスを許可する必要があります。また、https://evil.example.com には決してアクセスを許可しないようにする必要があります。各オリジンはウェブの他の部分から隔離されるため、デベロッパーはそこでビルドとプレイのための安全なサンドボックスを利用できます。理論的には、これは非常に優れた機能です。実際には、攻撃者が巧妙な方法でシステムを阻止しようとしています。

たとえば、クロスサイト スクリプティング（XSS）攻撃は、サイトを騙して悪意のあるコードを目的のコンテンツとともに配信することで、同一オリジン ポリシーをバイパスします。これは大きな問題です。ブラウザは、ページに表示されるすべてのコードを、そのページのセキュリティ オリジンの正当な部分として信頼するからです。XSS クイック リファレンスは、攻撃者が悪意のあるコードを注入してこの信頼を侵害するために使用する可能性のある、古い手法で代表的な手法です。攻撃者がなんらかのコードの注入に成功すると、ユーザー セッション データが侵害され、秘密にすべき情報が The Bad Guys に漏洩し、ゲームオーバーとなります。当然ながら、私たちは可能な限りそのような状況は回避したいと考えています。

この概要では、最新のブラウザにおける XSS 攻撃のリスクと影響を大幅に低減できる防御策である、コンテンツ セキュリティ ポリシー（CSP）について説明します。

要約

  • 許可リストを使用して、許可されるものと許可されないものをクライアントに伝える。
  • 使用可能なディレクティブを確認します。
  • 使用されているキーワードを確認する。
  • インライン コードと eval() は有害と見なされます。
  • 適用する前に、サーバーにポリシー違反を報告してください。

送信元の許可リスト

XSS 攻撃によって悪用される問題は、ブラウザがアプリケーションの一部であるスクリプトと、サードパーティによって悪意を持って注入されたスクリプトを区別できないことです。たとえば、このページの下部にある Google +1 ボタンは、このページの提供元のコンテキストで、https://apis.google.com/js/plusone.js からコードを読み込んで実行します。Google はそのコードを信頼していますが、apis.google.com のコードが優れていても、apis.evil.example.com のコードが必ずしもそうではないとブラウザが独自に判断することは期待できません。ブラウザは、ソースに関係なく、ページがリクエストしたコードを正しくダウンロードして実行します。

CSP は、サーバーが配信するすべてを盲目的に信頼するのではなく、Content-Security-Policy HTTP ヘッダーを定義します。これにより、信頼できるコンテンツのソースの許可リストを作成し、そのソースからのリソースのみを実行またはレンダリングするようブラウザに指示します。攻撃者がスクリプトを挿入するための穴を見つけても、そのスクリプトは許可リストと一致しないため、実行されません。

apis.google.com は有効なコードを配信することを信頼し、Google も同じことを信じています。そのため、次の 2 つのソースのいずれかから取得した場合にのみスクリプトの実行を許可するポリシーを定義しましょう。

Content-Security-Policy: script-src 'self' https://apis.google.com

実に簡単ですね。ご想像のとおり、script-src は、特定のページに対する一連のスクリプト関連の権限を制御するディレクティブです。ここでは、'self' と https://apis.google.com を有効なスクリプト ソースとして指定しています。ブラウザは、現在のページのオリジンから、また HTTPS 経由で apis.google.com から JavaScript を忠実にダウンロードして実行します。

コンソール エラー: スクリプト「http://evil.example.com/evil.js」の読み込みが拒否されました。これは、コンテンツ セキュリティ ポリシーのディレクティブ script-src 'self' https://apis.google.com に違反しているためです。

このポリシーを定義すると、ブラウザは他のソースからスクリプトを読み込む代わりに、単にエラーをスローします。巧妙な攻撃者がサイトにコードを注入しようとすると、予想していた成功とは言えず、むしろエラー メッセージが表示されてしまいます。

ポリシーがさまざまなリソースに適用される

スクリプト リソースは最も明白なセキュリティ リスクですが、CSP は豊富なポリシー ディレクティブを提供し、ページへの読み込みを許可するリソースをかなりきめ細かく制御できます。script-src についてはすでに説明したので、コンセプトは明確です。

残りのリソース ディレクティブについて簡単に見ていきましょう。以下のリストは、レベル 2 におけるディレクティブの状態を示しています。レベル 3 の仕様が公開されましたが、主要なブラウザでほとんど実装されていません。

  • base-uri は、ページの <base> 要素に表示できる URL を制限します。
  • child-src は、ワーカーと埋め込みフレーム コンテンツの URL を一覧表示します。たとえば、child-src https://youtube.com を使用すると、YouTube の動画を埋め込むことはできますが、他のオリジンの動画を埋め込むことはできません。
  • connect-src は、（XHR、WebSocket、EventSource を介して）接続できるオリジンを制限します。
  • font-src は、ウェブフォントを提供できるオリジンを指定します。Google のウェブフォントは font-src https://themes.googleusercontent.com で有効にできます。
  • form-action は、<form> タグから送信するために有効なエンドポイントをリストします。
  • frame-ancestors は、現在のページを埋め込むことができるソースを指定します。このディレクティブは、<frame>、<iframe>、<embed>、<applet> タグに適用されます。このディレクティブは <meta> タグでは使用できません。HTML 以外のリソースにのみ適用されます。
  • frame-src はレベル 2 で非推奨になりましたが、レベル 3 で復元されました。存在しない場合でも、以前と同様に child-src にフォールバックします。
  • img-src は、画像を読み込むことができるオリジンを定義します。
  • media-src は、動画と音声を配信できるオリジンを制限します。
  • object-src: Flash などのプラグインを制御できます。
  • plugin-types は、ページで呼び出せるプラグインの種類を制限します。
  • report-uri には、コンテンツ セキュリティ ポリシーに違反した場合にブラウザからレポートを送信する URL を指定します。このディレクティブは、<meta> タグでは使用できません。
  • style-src は、script-src のスタイルシートの版です。
  • upgrade-insecure-requests は、URL スキームを書き換えて HTTP を HTTPS に変更するようユーザー エージェントに指示します。このディレクティブは、書き換えが必要な古い URL が多数存在するウェブサイト向けです。
  • worker-src は、ワーカー、共有ワーカー、または Service Worker として読み込める URL を制限する CSP レベル 3 ディレクティブです。2017 年 7 月の時点で、このディレクティブの実装は制限されています。

デフォルトでは、ディレクティブは広く設定されています。font-src など、ディレクティブに特定のポリシーを設定しない場合、そのディレクティブは * を有効なソースとして指定した場合と同様にデフォルトで動作します（たとえば、任意の場所から制限なしでフォントを読み込むことができます）。

このデフォルトの動作は、default-src ディレクティブを指定することでオーバーライドできます。このディレクティブは、未指定のままにするほとんどのディレクティブのデフォルトを定義します。これは通常、末尾が -src のすべてのディレクティブに適用されます。default-src が https://example.com に設定されていて、font-src ディレクティブを指定しなかった場合、https://example.com からフォントを読み込むことはできますが、それ以外の場所には読み込むことができません。前の例では script-src のみを指定しました。つまり、画像やフォントなどはどのオリジンからでも読み込むことができます。

次のディレクティブは、default-src をフォールバックとして使用しません。設定しなければ、すべて許可したのと同じということを覚えておいてください。

  • base-uri
  • form-action
  • frame-ancestors
  • plugin-types
  • report-uri
  • sandbox

これらのディレクティブは、特定のアプリケーションに必要な数だけ使用することもできます。HTTP ヘッダーに各ディレクティブを記載して、ディレクティブをセミコロンで区切ります。特定のタイプの必須リソースをすべて 1 つのディレクティブに含めてリストするようにしてください。script-src https://host1.com; script-src https://host2.com のように記述すると、2 番目のディレクティブは無視されます。次のように、両方の送信元を有効なものとして正しく指定しています。

script-src https://host1.com https://host2.com

たとえば、コンテンツ配信ネットワーク（https://cdn.example.net など）からすべてのリソースを読み込むアプリで、フレーム化されたコンテンツやプラグインは不要なことがわかっている場合、ポリシーは次のようになります。

Content-Security-Policy: default-src https://cdn.example.net; child-src 'none'; object-src 'none'

実装の詳細

ウェブ上のさまざまなチュートリアルで、X-WebKit-CSP ヘッダーと X-Content-Security-Policy ヘッダーが使用されています。今後、これらの接頭辞付きのヘッダーは無視してください。最新のブラウザ（IE を除く）はプレフィックスなしの Content-Security-Policy ヘッダーをサポートしています。それが、使用すべきヘッダーです。

使用するヘッダーに関係なく、ポリシーはページごとに定義されます。保護したいすべてのレスポンスとともに HTTP ヘッダーを送信する必要があります。これにより、ニーズに基づいて特定のページのポリシーを微調整できるため、柔軟性が大幅に向上します。+1 ボタンがあるページとないページがあるなら、そのボタンコードの読み込みを必要なときだけ許可できます。

各ディレクティブのソースリストは柔軟性があります。送信元はスキーム（data:、https:）で指定できます。また、ホスト名のみ（example.com: そのホストの任意のオリジンに一致する: 任意のスキーム、ポート）から完全修飾 URI（https://example.com:443、HTTPS のみ、example.com のみ、ポート 443 のみと一致）まで、特定の範囲で送信元を指定できます。ワイルドカードも使用できますが、スキーム、ポート、またはホスト名の左端の位置でのみ使用できます。たとえば、*://*.example.com:* は example.com のすべてのサブドメインに一致しますが、example.com 自体には一致しません。その際、任意のポートで任意のスキームが使用されます。

ソースリストでは、次の 4 つのキーワードも指定できます。

  • 'none' は、当然のことながら、何も一致しません。
  • 'self' は現在のオリジンと一致しますが、サブドメインは一致しません。
  • 'unsafe-inline' は、インライン JavaScript と CSS を可能にします。（これについては後で詳しく説明します）。
  • 'unsafe-eval' を使用すると、eval のようなテキストから JavaScript へのメカニズムが可能になります。（これについてもお話しします）。

キーワードには一重引用符が必要です。たとえば、script-src 'self'（引用符付き）は、現在のホストからの JavaScript の実行を許可します。script-src self（引用符なし）は、"self" という名前のサーバーからの JavaScript を許可します（現在のホストからの JavaScript ではありません）。

サンドボックス化

もう 1 つ説明すべきディレクティブがあります。sandbox です。これは、これまで説明してきたものとは少し異なります。つまり、ページの読み込み可能なリソースではなく、ページで実行できるアクションを制限します。sandbox ディレクティブが存在する場合、ページは sandbox 属性が指定された <iframe> 内に読み込まれたかのように処理されます。これにより、ページを固有のオリジンに強制的に設定したり、フォームの送信を防止したりするなど、ページにさまざまな影響を及ぼす可能性があります。この記事の範囲外ですが、有効なサンドボックス属性の詳細については、HTML5 仕様の「サンドボックス化」セクションをご覧ください。

メタタグ

CSP が優先する配信メカニズムは HTTP ヘッダーです。ただし、マークアップでページに直接ポリシーを設定すると便利な場合があります。これを行うには、http-equiv 属性を含む <meta> タグを使用します。

<meta
  http-equiv="Content-Security-Policy"
  content="default-src https://cdn.example.net; child-src 'none'; object-src 'none'"
/>

これは frame-ancestors、report-uri、sandbox には使用できません。

インライン コードは有害と見なされる

CSP が許可リストのオリジンに基づいていることは明らかです。これは、特定のリソースセットを許容できるものとして扱い、残りは拒否するようにブラウザに指示する明確な方法です。ただし、送信元ベースの許可リストでは、XSS 攻撃の最大の脅威であるインライン スクリプト インジェクションは解決しません。攻撃者が悪意のあるペイロード（<script>sendMyDataToEvilDotCom();</script>）を直接含むスクリプトタグを挿入できる場合、ブラウザには正規のインライン スクリプトタグと区別するメカニズムがありません。CSP は、インライン スクリプトを完全に禁止することでこの問題を解決します。これが確認できる唯一の方法です。

この禁止対象には、script タグに直接埋め込まれたスクリプトだけでなく、インライン イベント ハンドラや javascript: URL も含まれます。script タグの内容を外部ファイルに移動し、javascript: URL と <a ... onclick="[JAVASCRIPT]"> を適切な addEventListener() 呼び出しに置き換える必要があります。たとえば、次のように書き換えます。

<script>
  function doAmazingThings() {
    alert('YOU AM AMAZING!');
  }
</script>
<button onclick="doAmazingThings();">Am I amazing?</button>

次のように変更します。

<!-- amazing.html -->
<script src="amazing.js"></script>
<button id="amazing">Am I amazing?</button>

<div style="clear:both;"></div>

// amazing.js
function doAmazingThings() {
  alert('YOU AM AMAZING!');
}
document.addEventListener('DOMContentLoaded', function () {
  document.getElementById('amazing').addEventListener('click', doAmazingThings);
});

書き直したコードには、CSP とうまく連携する以上の利点があります。これは、CSP を使用するかどうかにかかわらず、すでにベスト プラクティスです。インライン JavaScript によって、構造と動作が混在するのではありません。外部リソースはブラウザでキャッシュしやすく、デベロッパーにとっては理解しやすく、コンパイルと圧縮に役立ちます。コードを外部リソースに移動する作業を行うと、より適切なコードを作成できます。

インライン スタイルも同じように扱われます。style 属性と style タグの両方を外部スタイルシートに統合して、CSS で可能になる驚くほど巧妙なさまざまなデータ漏洩方法から保護する必要があります。

インラインのスクリプトとスタイルが必要な場合は、script-src または style-src ディレクティブで 'unsafe-inline' を許可されたソースとして追加することで、インライン スクリプトとスタイルを有効にできます。ノンスやハッシュを使用することもできますが（下記参照）、使用しないでください。 インライン スクリプトの禁止は、CSP が提供する最大のセキュリティです。インライン スタイルを禁止すると、同様にアプリケーションが強化されます。すべてのコードを行から外した後、正しく動作するようにするための多少の労力はかかりますが、トレードオフは十分に価値があります。

どうしてもファイアウォール ルールを

CSP レベル 2 では、暗号化のノンス（1 回使用される番号）またはハッシュのいずれかを使用して特定のインライン スクリプトを許可リストに追加できるようにすることで、インライン スクリプトの下位互換性を提供します。これは煩雑ですが、必要な場合には便利です。

ノンスを使用するには、スクリプトタグにノンス属性を設定します。この値は、信頼できるソースのリストの値と一致する必要があります。次に例を示します。

<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa">
  // Some inline code I can't remove yet, but need to asap.
</script>

次に、nonce- キーワードに追加した script-src ディレクティブにノンスを追加します。

Content-Security-Policy: script-src 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa'

ノンスはページ リクエストごとに再生成する必要があり、推測できないものにする必要があります。

ハッシュの仕組みはほぼ同じです。スクリプトタグにコードを追加する代わりに、スクリプト自体の SHA ハッシュを作成して script-src ディレクティブに追加します。たとえば、ページに次のようなコンテンツがあるとします。

<script>
  alert('Hello, world.');
</script>

ポリシーは次のようになります。

Content-Security-Policy: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng='

ここで注目すべき点がいくつかあります。sha*- 接頭辞は、ハッシュを生成するアルゴリズムを指定します。上記の例では、sha256- を使用しています。CSP は sha384- と sha512- もサポートしています。ハッシュを生成するときに、<script> タグを含めないでください。また、先頭や末尾の空白文字を含め、大文字と空白文字も重要です。

SHA ハッシュの生成について Google 検索を行うと、さまざまな言語のソリューションが見つかります。Chrome 40 以降では、DevTools を開いてページを再読み込みできます。[コンソール] タブに、各インライン スクリプトの正しい SHA256 ハッシュを示すエラー メッセージが表示されます。

評価も行う

攻撃者がスクリプトを直接挿入できない場合でも、アプリケーションをだまして、本来なら不活性なテキストを実行可能な JavaScript に変換し、代わりに実行させることができる可能性があります。eval()、new Functions()、setTimeout([string], ...)、setInterval([string], ...) はすべてベクトルです。これらのベクトルは、挿入されたテキストによって予期せぬ悪意のある動作を引き起こす可能性があります。このリスクに対する CSP のデフォルトの対応は、これらのベクトルをすべて完全にブロックすることです。

これは、アプリケーションの構築方法にいくつかの点だけに影響します。

  • eval に依存するのではなく、組み込みの JSON.parse を使用して JSON を解析する必要があります。ネイティブ JSON オペレーションは IE8 以降のすべてのブラウザで使用でき、完全に安全です。
  • 文字列ではなく、インライン関数を使用して、現在行っている setTimeout または setInterval の呼び出しを書き換えます。次に例を示します。
setTimeout("document.querySelector('a').style.display = 'none';", 10);

次のように記述するとよいでしょう。

setTimeout(function () {
  document.querySelector('a').style.display = 'none';
}, 10);
  • 実行時にインライン テンプレートを使用しない: 多くのテンプレート ライブラリで new Function() をふんだんに使用し、実行時のテンプレート生成を高速化します。これは動的プログラミングの優れた応用例ですが、悪意のあるテキストが評価されるリスクがあります。一部のフレームワークは CSP をすぐにサポートしており、eval がなくても堅牢なパーサーにフォールバックします。AngularJS の ng-csp ディレクティブが良い例です。

ただし、プリコンパイルが可能なテンプレート言語のほうが適しています（Handlebars など）。テンプレートをプリコンパイルすると、最速のランタイム実装よりもユーザー エクスペリエンスを高速化でき、安全性も向上します。eval およびその text-to-JavaScript のクラスがアプリケーションに不可欠な場合は、許可されたソースとして 'unsafe-eval' を script-src ディレクティブに追加することで有効化できますが、おすすめしないことを強くおすすめします。文字列の実行を禁止すると、攻撃者がサイトで不正なコードを実行することが難しくなります。

レポート

CSP が信頼できないリソースをクライアントサイドでブロックできることは、ユーザーにとって非常に有用ですが、なんらかの通知をサーバーに返送することで、悪意のあるインジェクションを許すバグをそもそも特定して排除することができます。これは非常に便利です。これを行うには、report-uri ディレクティブで指定された場所に JSON 形式の違反レポートを POST するようブラウザに指示します。

Content-Security-Policy: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;

レポートは次のようになります。

{
  "csp-report": {
    "document-uri": "http://example.org/page.html",
    "referrer": "http://evil.example.com/",
    "blocked-uri": "http://evil.example.com/evil.js",
    "violated-directive": "script-src 'self' https://apis.google.com",
    "original-policy": "script-src 'self' https://apis.google.com; report-uri http://example.org/my_amazing_csp_report_parser"
  }
}

この情報には、違反が発生したページ（document-uri）、そのページの参照 URL（HTTP ヘッダー フィールドとは異なり、キーにスペルミスはありません）、ページのポリシーに違反したリソース（blocked-uri）、違反した特定のディレクティブ（violated-directive）、ページのポリシーの完全なポリシー（original-policy）など、違反の具体的な原因を突き止めるための多くの情報が含まれています。

レポート専用

CSP を使い始めたばかりの場合は、ユーザーに厳格なポリシーを展開する前に、アプリケーションの現在の状態を評価することをおすすめします。完全なデプロイへの足がかりとして、ブラウザにポリシーをモニタリングし、違反を報告しても制限を適用しないように指示できます。Content-Security-Policy ヘッダーではなく、Content-Security-Policy-Report-Only ヘッダーを送信します。

Content-Security-Policy-Report-Only: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;

レポート専用モードで指定されたポリシーは、制限付きリソースをブロックしませんが、指定したロケーションに違反レポートを送信します。両方のヘッダーを送信して、一方のポリシーを適用して、もう一方のポリシーをモニタリングすることもできます。これは、アプリケーションの CSP の変更による影響を評価するのに最適な方法です。新しいポリシーの報告を有効にし、違反レポートをモニタリングし、見つかったバグを修正します。その効果に問題がなければ、新しいポリシーの適用を開始します。

実際の使用状況

CSP 1 は Chrome、Safari、Firefox で使用できますが、IE 10 でのサポートは非常に限定的です。詳しくは、caniuse.com をご覧ください。CSP レベル 2 は、Chrome バージョン 40 以降で使用できます。Twitter や Facebook などの巨大なサイトでこのヘッダーがデプロイされており（Twitter のケーススタディ）、この標準はすぐに独自のサイトへのデプロイを開始できます。

アプリケーションのポリシーを作成するための最初のステップは、実際に読み込むリソースを評価することです。アプリ内での要素をどのようにまとめるかを把握したら、その要件に基づいてポリシーを設定します。一般的なユースケースをいくつか説明して、CSP の保護範囲内で最適なサポート方法を判断しましょう。

ユースケース #1: ソーシャル メディア ウィジェット

  • Google の +1 ボタンには https://apis.google.com のスクリプトと、https://plusone.google.com の <iframe> が埋め込まれています。ボタンを埋め込むには、これらのオリジンの両方を含むポリシーが必要です。最小ポリシーは script-src https://apis.google.com; child-src https://plusone.google.com です。また、Google が提供する JavaScript のスニペットが外部の JavaScript ファイルに取り出されるようにする必要もあります。frame-src を使用するレベル 1 ベースのポリシーがある場合、レベル 2 では child-src に変更する必要があります。これは、CSP レベル 3 では不要です。

  • Facebook の [Like] ボタンには、さまざまな実装オプションがあります。<iframe> バージョンは、サイトの他の部分から安全にサンドボックス化されているため、使用することをおすすめします。適切に機能させるには、child-src https://facebook.com ディレクティブが必要です。デフォルトでは、Facebook が提供する <iframe> コードは相対 URL //facebook.com を読み込みます。これを変更して、HTTPS を明示的に指定します（https://facebook.com）。HTTP を使用する必要がなければ、何も理由はありません。

  • Twitter のツイートボタンは、どちらも https://platform.twitter.com でホストされているスクリプトとフレームへのアクセス権に依存しています。（同様に Twitter でもデフォルトで相対 URL が提供されます。ローカルでコピー&ペーストするときはコードを編集して HTTPS を指定します）。Twitter から提供された JavaScript スニペットを外部の JavaScript ファイルに移動する限り、script-src https://platform.twitter.com; child-src https://platform.twitter.com で準備完了です。

  • 他のプラットフォームにも同様の要件があり、同様に対処できます。default-src を 'none' に設定し、コンソールを監視して、ウィジェットを機能させるために有効化する必要があるリソースを確認することをおすすめします。

複数のウィジェットを含めるのは簡単です。ポリシー ディレクティブを結合するだけです。同じタイプのすべてのリソースを 1 つのディレクティブにマージします。3 つのソーシャル メディア ウィジェットすべてが必要な場合、ポリシーは次のようになります。

script-src https://apis.google.com https://platform.twitter.com; child-src https://plusone.google.com https://facebook.com https://platform.twitter.com

ユースケース 2: ロックダウン

ここでは、銀行サイトを運営していて、自分で作成したリソースのみを読み込めるようにしたいとします。このシナリオでは、すべてを完全にブロックするデフォルトのポリシー（default-src 'none'）から始めて、そこからビルドをしていきます。

銀行が https://cdn.mybank.net の CDN からすべての画像、スタイル、スクリプトを読み込み、XHR を介して https://api.mybank.com/ に接続して、さまざまなデータを pull しているとします。フレームはサイトのローカルページにのみ使用されます（サードパーティのオリジンはありません）。サイトには Flash、フォント、追加要素はありません送信できる最も制限の厳しい CSP ヘッダーは次のとおりです。

Content-Security-Policy: default-src 'none'; script-src https://cdn.mybank.net; style-src https://cdn.mybank.net; img-src https://cdn.mybank.net; connect-src https://api.mybank.com; child-src 'self'

ユースケース 3: SSL のみ

結婚指輪ディスカッション フォーラムの管理者が、すべてのリソースが安全なチャネルを介してのみ読み込まれるようにしたいと考えていますが、あまりコードを記述する時間はありません。インライン スクリプトやスタイルでいっぱいのサードパーティ フォーラム ソフトウェアを大量に書き直すことは、とても難しいことです。有効なポリシーは次のとおりです。

Content-Security-Policy: default-src https:; script-src https: 'unsafe-inline'; style-src https: 'unsafe-inline'

https: が default-src で指定されていても、スクリプトとスタイル ディレクティブがそのソースを自動的に継承することはありません。各ディレクティブは、特定の種類のリソースのデフォルトを完全に上書きします。

今後の計画

コンテンツ セキュリティ ポリシー レベル 2 は 推奨事項候補です。W3C の Web Application Security Working Group では、この仕様の次のイテレーションである Content Security Policy Level 3 の作業をすでに開始しています。

今後リリースされる機能に関するディスカッションに興味がある場合は、public-webappsec@ メーリング リストのアーカイブに目を通すか、ご自身に参加してください。

フィードバック