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

コンテンツセキュリティポリシー（CSP）は、 信頼できるウェブページのコンテキストで悪意のあるコンテンツを実行することで発生するクロスサイトスクリプティング（XSS）、クリックジャッキング、その他のコードインジェクション攻撃を防ぐために導入されたコンピュータセキュリティ標準です。^{[1]これは、} W3Cのウェブアプリケーションセキュリティワーキンググループの勧告候補であり、 ^[2]最新のウェブブラウザで広くサポートされています。^[3] CSPは、ウェブサイトの所有者がブラウザがそのウェブサイトで読み込むことを許可される承認済みコンテンツのオリジンを宣言するための標準的な方法を提供します。対象となるタイプは、JavaScript、CSS、HTMLフレーム、ウェブワーカー、フォント、画像、 Javaアプレット、ActiveX 、オーディオファイルやビデオファイルなどの埋め込み可能オブジェクト、その他のHTML5機能です。

この標準規格は、もともとコンテンツ制限と呼ばれ、2004年にロバート・ハンセン氏によって提案され、^[4] Firefox 4で初めて実装され、すぐに他のブラウザにも採用されました。この標準規格のバージョン1は、2012年にW3Cの候補勧告として公開され^[5]、その後すぐに2014年にさらなるバージョン（レベル2）が公開されました。2023年現在^{[アップデート]}、レベル3のドラフトが開発されており、新しい機能はウェブブラウザに急速に採用されています。^[6]

以下のヘッダー名は実験的なCSP実装の一部として使用されています: ^[3]

• Content-Security-Policy– W3C文書で提案された標準ヘッダー名。Google Chromeはバージョン25からこれをサポートしています。^[7] Firefoxはバージョン23からこれをサポートしています。^[8] 2013年8月6日にリリースされました。 ^[9] WebKitはバージョン528（ナイトリービルド）からこれをサポートしています。^[10] ChromiumベースのMicrosoft EdgeのサポートはChromeと同様です。^[11]
• X-WebKit-CSP– 2011年にGoogle Chrome、Safari、その他のWebKitベースのウェブブラウザに導入された非推奨の実験的なヘッダー。 ^[12]
• X-Content-Security-Policy– Gecko 2ベースのブラウザ（Firefox 4からFirefox 22、Thunderbird 3.3、SeaMonkey 2.1）で導入された非推奨の実験的なヘッダー。 ^[13]

ウェブサイトは複数の CSP ヘッダーを宣言でき、強制ヘッダーとレポート専用ヘッダーを混在させることもできます。各ヘッダーはブラウザによって個別に処理されます。

CSPはメタタグを使用してHTMLコード内で配信することもできますが、この場合、その効果は限られます。^[14]

Internet Explorer 10とInternet Explorer 11もCSPをサポートしていますが、実験的なX-Content-Security-Policyヘッダーを使用するサンドボックスディレクティブのみです。^[15]

多くのWebアプリケーションフレームワークがCSPをサポートしています。たとえば、AngularJS ^[16] (ネイティブ) やDjango (ミドルウェア) ^{[17]などです。} Ruby on Railsの説明はGitHubに投稿されています。^[18]ただし、Webフレームワークのサポートは、CSPの内容がWebアプリケーションの状態に何らかの形で依存する場合 (オリジンの使用など) にのみ必要です。 それ以外の場合、CSPはむしろ静的であり、ロードバランサーやWebサーバーなど、アプリケーションの上位のWebアプリケーション層nonceから配信できます。

2015年12月^[19] と2016年12月^[20]には、ホワイトリストのオリジンをバイパスする方法がいくつか'nonce'公開されました。2016年1月には^{[21] 、サーバー全体のCSPホワイトリストを利用して、同じサーバーでホストされているJavaScriptライブラリの古くて脆弱なバージョンを悪用する別の方法が公開されました（CDNサーバーではよくあるケース）。2017年5月には[22]、} Webアプリケーションフレームワークコードを使用してCSPをバイパスする別の方法が公開されました。

ヘッダーがサーバーの応答に存在する場合Content-Security-Policy、準拠しているクライアントは宣言型ホワイトリスト ポリシーを適用します。ポリシーの目標の 1 つは、特定のクロスサイト スクリプティング攻撃を防ぐために、JavaScript の実行モードを厳格化することです。実際には、これはいくつかの機能がデフォルトで無効になっていることを意味します。

• インラインJavaScriptコード^[a]
  • <script>ブロック、^[b]
  • DOMイベント ハンドラーを HTML 属性として (例onclick)
  • リンクjavascript:​
• インラインCSSステートメント
  • <style>ブロック^[b]
  • styleHTML要素に帰属する
• 動的JavaScriptコード評価^[c]
  • eval()
  • setTimeoutおよびsetInterval関数の文字列引数
  • new Function()コンストラクタ
• 動的CSSステートメント
  • CSSStyleSheet.insertRule()方法

新しいアプリケーションでCSPを使用することは、特にCSP互換のJavaScriptフレームワークを使用すると非常に簡単ですが、^[d]既存のアプリケーションではリファクタリング、またはポリシーの緩和が必要になる場合があります。CSP互換のWebアプリケーションに推奨されるコーディング方法は、外部ソースファイル（<script src>）からコードを読み込み、JSONを評価するのではなく解析し、EventTarget.addEventListener()イベントハンドラーを設定するために使用することです。^[23]

要求されたリソースまたはスクリプトの実行がポリシーに違反した場合、ブラウザは違反の詳細を含む ^[24]または ^[25]POSTで指定された値にリクエストを送信します。report-urireport-to

CSPレポートは標準的なJSON構造であり、アプリケーション独自のAPI ^[26]またはパブリックCSPレポートレシーバーによってキャプチャできます。^{[引用が必要]}

2018年にセキュリティ研究者は、で指定された受信者に誤検知レポートを送信する方法を示しましたreport-uri。これにより、潜在的な攻撃者がこれらのアラームを任意にトリガーできるようになり、実際の攻撃の際にアラームの有用性が低下する可能性があります。^[27]この動作は意図されたものであり、ブラウザ（クライアント）がレポートを送信しているため、修正することはできません。

オリジナルのCSP（1.0）処理モデル（2012～2013年）によれば、^[28] CSPはユーザーがインストールしたブラウザのアドオンや拡張機能の動作を妨害してはならない。CSPのこの機能により、スクリプトの出所に関係なく、あらゆるアドオン、拡張機能、ブックマークレットがWebサイトにスクリプトを挿入することが事実上許可され、CSPポリシーの適用外となる。

^{しかし、このポリシーはその後（CSP 1.1 [29]} 以降）次のように変更されました。以前の絶対的な「すべき（すべきではない）」という表現の代わりに、「してもよい」という単語が使用されていることに注意してください。

注: ユーザー エージェントでは、ユーザー設定、ブックマークレット、ユーザー エージェントへのサードパーティの追加、およびその他の同様のメカニズムを通じて、ユーザーがポリシーの適用を変更またはバイパスできるようにする場合があります。

絶対的な「すべき」という文言は、ブラウザのユーザーがポリシーの遵守を要求/要求し、一般的なブラウザ（Firefox、Chrome、Safari）にポリシーをサポートする変更をインストールするために使用されていました。これは、TwitterやGitHubなどのサイトが強力なCSPポリシーを使用し始め、ブックマークレットの使用を「破壊」したときに特に物議を醸しました。^[30]

W3Cウェブアプリケーションセキュリティワーキンググループは、このようなスクリプトをブラウザによって実装されたトラステッドコンピューティングベースの一部と見なしています。しかし、 Cox Communicationsの代表者は、この例外は悪意のあるアドオンや拡張機能によって悪用される可能性のある潜在的なセキュリティホールであるとワーキンググループに主張しました。 ^{[31] [32]}

2015年現在、^{[アップデート]}W3Cではいくつかの新しいブラウザセキュリティ標準が提案されており、そのほとんどはCSPを補完するものである。^[33]

• サブリソース整合性( SRI ) は、既知の信頼できるリソース ファイル (通常はJavaScript、 CSS ) のみがサードパーティのサーバー (通常はCDN )
• 混合コンテンツ： HTTPS経由で読み込まれたページとプレーンテキストHTTP経由でリンクされたコンテンツに関するブラウザのポリシーを明確にする
• 安全でないリクエストのアップグレード、 HTTPSに移行されたページ上のレガシーリンクの処理方法をブラウザに示唆
• 認証情報管理、複雑なログインスキームを容易にするためにユーザーの認証情報にアクセスするための統合JavaScript API 、
• Referrer Policyは、 Refererヘッダーの生成時にブラウザにヒントを与えるCSP拡張機能です。^[33]

• 同一生成元ポリシー
• NoScript – XSS対策とアプリケーション境界強制機能（ABE）、Firefoxの拡張機能^{[34] [35]}
• HTTPスイッチボード– ユーザー定義のCSPルール、Google Chrome ^[36]およびOpera ^{[37]の拡張機能}
• HTTP 厳格なトランスポートセキュリティ
• HTTP 公開鍵のピン留め

• コンテンツ セキュリティ ポリシー W3C ワーキング ドラフト
• コンテンツセキュリティポリシーのための安全なコーディングガイドライン
• MDN Web Docsのコンテンツ セキュリティ ポリシー (CSP)