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

Joe Medley
Joe Medley
GitHub

ウェブのセキュリティ モデルのルートは同一オリジン ポリシーです。https://mybank.com からのコードは https://mybank.com のデータにのみアクセスでき、https://evil.example.com にはアクセスを許可しないようにする必要があります。各オリジンはウェブの他の部分から分離されているため、デベロッパーは安全にサンドボックスを構築してプレイできます。理論上は、これは完璧です。実際には、攻撃者は巧妙な方法を見つけてシステムを破壊します。

たとえば、クロスサイト スクリプティング（XSS）攻撃は、サイトをだまして、意図されたコンテンツとともに悪意のあるコードを配信させることで、同一オリジン ポリシーを回避します。これは大きな問題です。ブラウザは、ページに表示されるすべてのコードを、そのページのセキュリティ オリジンに正当に組み入れたものとして信頼するためです。XSS クイック リファレンスは、攻撃者が悪意のあるコードを注入してこの信頼を侵害するために使用する可能性のある手法のうち、古いものだが代表的な例です。攻撃者がなんらかのコードの挿入に成功した場合は、ゲームオーバーです。ユーザー セッション データが侵害され、秘密にすべき情報が不正に流出されます。できれば、それを避けたいと考えています。

この概要では、最新のブラウザにおける 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 は有効なコードを提供することを信頼し、それも同様に実行することを信頼しているため、次の 2 つのソースのいずれかから送信された場合にのみスクリプトの実行を許可するポリシーを定義します。

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

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

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

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

ポリシーはさまざまなリソースに適用

スクリプト リソースは最も明白なセキュリティ リスクですが、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' では、テキストから JavaScript のメカニズム（eval など）を使用できます。（これについても取り上げます）。

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

サンドボックス化

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

meta タグ

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' を追加することで有効にできます。nonce または hash（以下を参照）を使用することもできますが、使用しないでください。 インライン スクリプトを禁止することは、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()、新しい Function()、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 の兄弟機能がアプリケーションに不可欠な場合は、script-src ディレクティブで許可されたソースとして 'unsafe-eval' を追加することで有効にできますが、この方法はおすすめしません。文字列の実行を禁止すると、攻撃者がサイトで不正なコードを実行することが難しくなります。

報告

信頼できないリソースをクライアントサイドでブロックする 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;

レポート専用モードで指定されたポリシーでは制限付きリソースはブロックされませんが、指定したロケーションに違反レポートが送信されます。両方のヘッダーを送信して、1 つのポリシーを適用し、別のポリシーを適用することもできます。これは、アプリケーションの 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 ファイルに pull されるようにする必要もあります。frame-src を使用するレベル 1 ベースのポリシーがある場合、レベル 2 では child-src に変更する必要があります。これは CSP レベル 3 では不要になります。

  • Facebook の [いいね] ボタンには、さまざまな実装オプションがあります。サイトの他の部分から安全にサンドボックス化されているため、常に <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 つのタイプのすべてのリソースを 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'

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

今後の計画

コンテンツ セキュリティ ポリシー レベル 2 は 推奨事項候補です。W3C のウェブ アプリケーション セキュリティ ワーキング グループは、この仕様の次のイテレーションであるコンテンツ セキュリティ ポリシー レベル 3 の作業をすでに始めています。

今後追加される機能に関するディスカッションに関心をお持ちの場合は、public-webappsec@ メーリング リストのアーカイブをご覧ください。または、ご自身でも参加できます。

フィードバック