Content Security Policy

Content Security Policy（コンテンツセキュリティポリシー、略称: CSP）は、ウェブサイトのセキュリティを強化するための仕組みである。CSPは、ウェブサイトの所有者が、そのサイトが読み込むことを許可するコンテンツの種類や、どこからコンテンツを読み込むかをブラウザに明確に指示するための、セキュリティ標準を定義したものである。これにより、クロスサイトスクリプティング（XSS）、クリックジャッキング、その他のコードインジェクション攻撃などの攻撃からウェブサイトを保護する。

対象となるコンテンツの種類は、JavaScript、CSS、HTMLフレーム、ウェブワーカー、フォント、画像、Javaアプレット、ActiveX、音声・動画ファイルなどの埋め込み可能オブジェクト、およびその他のHTML5機能である。World Wide Web Consortium（W3C）のウェブアプリケーションセキュリティワーキンググループで勧告され、現代のウェブブラウザに広くサポートされている。

概要

この基準は、元々「Content Restrictions」という名前で2004年にRobert Hansenによって提案された。最初にFirefox 4で実装され、その後すぐに他のブラウザにも採用された。このバージョン1は、2012年にW3C勧告候補として公開され、その後すぐに2014年にはさらなるLevel 2が公開された。その後、Level 3の草案が開発中であり、新機能はウェブブラウザに迅速に採用されている。

ウェブサイトは複数のCSPヘッダを宣言でき、強制モードとレポート専用モードを混在させることもできる。各ヘッダはブラウザによって個別に処理される。CSPはmeta要素を使用してHTMLコード内で配信することもできるが、この場合その有効性は限定的となる。

多くのウェブアプリケーションフレームワークがCSPをサポートしている。例えば、AngularJS（ネイティブ）やDjango（ミドルウェア）がある。Ruby on Railsの手順はGitHubによって公開されている。しかし、フレームワークのサポートが必要となるのは、CSPの内容がnonceオリジンの使用など、何らかの形でウェブアプリケーションの状態に依存する場合のみである。そうでなければ、CSPはむしろ静的であり、ロードバランサやウェブサーバなど、アプリケーションより上位のウェブアプリケーション層から配信することができる。

ヘッダ名

CSP実装の一部として、以下のヘッダ名が使用されている。

  • Content-Security-Policy – W3Cの文書で提案された標準ヘッダ。Google Chromeではバージョン25から、Firefoxではバージョン23からこれをサポートしている。2013年8月6日にリリース。WebKitはバージョン528（ナイトリービルド）からこれをサポートしている。ChromiumベースのMicrosoft EdgeのサポートはChromeと同様である。
  • X-WebKit-CSP – 2011年にGoogle Chrome、Safari、およびその他のWebKitベースのウェブブラウザに導入された。現在では非推奨の実験的ヘッダである。
  • X-Content-Security-Policy – Gecko 2ベースのブラウザ（Firefox 4からFirefox 22、Thunderbird 3.3、SeaMonkey 2.1）に導入された。現在では非推奨の実験的ヘッダである。Internet Explorer 10およびInternet Explorer 11もCSPをサポートしているが、実験的なX-Content-Security-Policyヘッダを使用したsandboxディレクティブのみである。

バイパス

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

動作

HTML5とJavaScriptの機能とコンテンツセキュリティポリシーの制御との対応関係

サーバーの応答にContent-Security-Policyヘッダが存在する場合、準拠したクライアントは宣言的な許可リストポリシーを強制する。ポリシーの目標の一例は、特定のクロスサイトスクリプティング攻撃を防ぐために、JavaScriptの実行モードをより厳格にすることである。実際には、これにより多くの機能がデフォルトで無効になる。

新しいアプリケーションでCSPを使用するのは、特にCSP互換のJavaScriptフレームワークを使えば非常に簡単かもしれないが、既存のアプリケーションでは何らかのリファクタリング、あるいはポリシーの緩和が必要になる場合がある。CSP互換のウェブアプリケーションに推奨されるコーディングプラクティスは、外部ソースファイルからコードをロードし（<script src>）、JSONを評価するのではなくパースし、EventTarget.addEventListener()を使用してイベントハンドラを設定することである。

レポート

リクエストされたリソースやスクリプトの実行がポリシーに違反するたびに、ブラウザはreport-uriまたはreport-toで指定された値に、違反の詳細を含むPOSTリクエストを送信する。

CSPレポートは標準的なJSON構造であり、アプリケーション独自のAPIまたは公開されているCSPレポート受信サービスによって捕捉できる。

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

ブラウザアドオンと拡張機能との相性

当初のCSP（1.0）処理モデル（2012年～2013年）によると、CSPはユーザーがインストールしたブラウザのアドオンや拡張機能の動作を妨げるべきではないとされていた。CSPのこの機能は、事実上、アドオン、拡張機能、またはブックマークレットが、そのスクリプトのオリジンに関係なくウェブサイトにスクリプトを注入することを許可し、したがってCSPポリシーから免除されることを意味していた。

しかし、このポリシーはその後（CSP 1.1の時点で）次のような文言に修正された。以前の絶対的な「should (not)」という表現の代わりに、「may」という単語が使用されていることに注意されたい。

注：ユーザーエージェントは、ユーザー設定、ブックマークレット、ユーザーエージェントへのサードパーティ製の追加機能、およびその他の同様のメカニズムを通じて、ユーザーがポリシーの強制を変更またはバイパスすることを許可してもよい（may）。

この絶対的な「should」という文言は、ブラウザのユーザーがポリシーの遵守を要求・要望し、人気のあるブラウザ（Firefox、Chrome、Safari）にそれをサポートするための変更をインストールさせるために使われていた。これは、TwitterやGitHubのようなサイトが強力なCSPポリシーを使用し始め、ブックマークレットの使用を「破壊」したときに特に議論を呼んだ。

W3Cのウェブアプリケーションセキュリティワーキンググループは、このようなスクリプトをブラウザによって実装されたTrusted Computing Baseの一部であると考えている。しかし、この免除は、悪意のあるアドオンや拡張機能によって悪用される可能性のあるセキュリティホールであると、Cox Communicationsの代表者によってワーキンググループによって主張されている。

補完的な対策

W3Cによって多くの新しいブラウザセキュリティ基準が提案されており、そのほとんどはCSPを補完するものである。

関連項目

脚注

注釈

  1. ↑ This behavior can be disabled globally by a special 'unsafe-inline' statement
  2. 1 2 Trusted inline <script> and <style> blocks can be individually allowlisted in the CSP using nonce or hash statements.
  3. ↑ This behavior can be disabled globally by a special 'unsafe-eval' statement
  4. ↑ For example, AngularJS requires only one initialization flag to be switched into the CSP-compatible mode—<html ng-app='' ng-csp=''>

出典

  1. ↑ Sid Stamm (2009年3月11日). “Security/CSP/Spec - MozillaWiki” (英語). wiki.mozilla.org. 2025年7月29日閲覧。 “Content Security Policy is intended to help web designers or server administrators specify how content interacts on their web sites. It helps mitigate and detect types of attacks such as XSS and data injection.”
  2. ↑ “State of the draft” (英語) (2016年9月13日). 2025年7月29日閲覧。
  3. 1 2 “Can I use Content Security Policy?” (英語). Fyrd. 2025年7月29日閲覧。
  4. ↑ Robert Hansen (2009年6月1日). “Mozilla's Content Security Policy” (英語). 2015年3月18日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。 “Content Restrictions - a way for websites to tell the browser to raise their security on pages where the site knows the content is user submitted and therefore potentially dangerous.”
  5. ↑ “Content Security Policy 1.0” (英語). W3C. 2025年7月29日閲覧。
  6. ↑ “Content Security Policy Level 3” (英語). W3C. 2025年7月29日閲覧。
  7. ↑ “HTML META element” (英語). Content Security Policy Level 2. W3C. 2025年7月29日閲覧。
  8. ↑ “ngCsp directive” (英語). AngularJS. 2025年7月29日閲覧。
  9. ↑ “Chrome 25 Beta: Content Security Policy and Shadow DOM” (英語). Google (2013年1月14日). 2025年7月29日閲覧。
  10. ↑ “Content Security Policy 1.0 lands in Firefox Aurora” (英語). Mozilla Foundation (2013年5月29日). 2025年7月29日閲覧。
  11. ↑ “RapidRelease/Calendar” (英語). Mozilla Foundation (2013年5月29日). 2025年7月29日閲覧。
  12. ↑ “Bug 96765 - Implement the "Content-Security-Policy" header” (英語). WebKit (2012年10月31日). 2025年7月29日閲覧。
  13. ↑ “Content Security Policy (CSP)” (英語). Microsoft. 2025年7月29日閲覧。
  14. ↑ “New Chromium security features, June 2011” (英語). Google (2011年6月14日). 2025年7月29日閲覧。
  15. ↑ “Introducing Content Security Policy” (英語). Mozilla Foundation. 2025年7月29日閲覧。
  16. ↑ “Defense in Depth: Locking Down Mash-Ups with HTML5 Sandbox” (英語). Windows Internet Explorer Engineering Team. 2025年7月29日閲覧。
  17. ↑ “CSP 2015” (英語). XSS Jigsaw (2015年11月23日). 2015年12月20日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
  18. ↑ Lekies, Sebastian. “Collection of CSP bypasses” (英語). 2025年7月29日閲覧。
  19. ↑ “An Abusive Relationship with AngularJS” (英語) (2015年12月12日). 2025年7月29日閲覧。
  20. ↑ OWASP (2017-05-25) (英語), AppSec EU 2017 Don't Trust The DOM: Bypassing XSS Mitigations Via Script Gadgets by Sebastian Lekies 2017年6月5日閲覧。
  21. ↑ West, Mike (2012年6月15日). “An Introduction to Content Security Policy” (英語). HTML5 Rocks. 2025年7月29日閲覧。
  22. ↑ “Content Security Policy Level 3” (英語). www.w3.org. 2025年7月29日閲覧。
  23. ↑ “CSP: report-to - HTTP | MDN” (英語). developer.mozilla.org. 2025年7月29日閲覧。
  24. ↑ 例えば、Djangoでは、CSPレシーバーがdjango-securityモジュールで利用可能である。
  25. ↑ “Flaring The Blue Team - When You Confuse Them You Lose Them” (英語). Secjuice (2018年11月4日). 2025年7月29日閲覧。
  26. ↑ “CSP Processing Model” (英語) (2012年11月15日). 2025年7月29日閲覧。
  27. ↑ “CSP 1.1: Add non-normative language for extensions.” (英語). GitHub w3c webappsec. GitHub (2014年2月27日). 2025年7月29日閲覧。
  28. ↑ “Bug 866522 - Bookmarklets affected by CSP” (英語). Bugzilla. Mozilla (2013年4月28日). 2025年7月29日閲覧。
  29. ↑ “Subverting CSP policies for browser add-ons (extensions).” (英語) (2013年9月25日). 2025年7月29日閲覧。
  30. ↑ “Re: [CSP Request to amend bookmarklet/extensions sentence in CSP1.1]” (英語) (2014年8月3日). 2025年7月29日閲覧。
  31. 1 2 “Web Application Security Working Group” (英語). GitHub. 2025年7月29日閲覧。
  32. ↑ “Noscript security suite addon for Firefox” (英語). addons.mozilla.org. 2025年7月29日閲覧。
  33. ↑ “The NoScript Firefox extension — Official site” (英語). noscript.net. 2025年7月29日閲覧。
  34. ↑ “HTTP Switchboard for Opera” (英語). addons.opera.com. 2025年7月29日閲覧。

外部リンク