Content Security Policyとは？わかりやすく解説

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

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

概要

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

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

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

ヘッダ名

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

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

バイパス

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

動作

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

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

インラインJavaScriptコード^{[注釈 1]}
- <script>ブロック^{[注釈 2]}
- HTML属性としてのDOMイベントハンドラ（例: onclick）
- javascript:リンク
インラインCSS文
- <style>ブロック^{[注釈 2]}
- HTML要素に付けられたstyle属性
動的なJavaScriptコード評価^{[注釈 3]}
- eval()
- setTimeoutおよびsetInterval関数への文字列引数
- new Function()コンストラクタ
動的なCSS文
- CSSStyleSheet.insertRule()メソッド

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

レポート

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

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

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

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

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

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

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

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

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

補完的な対策

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

Subresource Integrity（SRI）：CDNなどのサードパーティのサーバーから、既知で信頼されたリソースファイル（通常はJavaScript、CSS）のみが読み込まれるようにするためのもの。
混合コンテンツ（Mixed Content）：HTTPS経由で読み込まれ、平文のHTTP経由のコンテンツにリンクしているページに対する、意図されたブラウザのポリシーを明確にするためのもの。
Upgrade Insecure Requests：HTTPSに移行したページ上のレガシーリンクをどのように処理するかをブラウザに示唆するためのもの。
Credential Management：複雑なログインスキームを容易にするために、ユーザーの資格情報にアクセスするための統一されたJavaScriptのAPI。
Referrer Policy：リファラヘッダの生成についてブラウザに示唆するためのCSP拡張^[31]。

脚注

[脚注の使い方]

注釈

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

出典

^ 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.”
^ “State of the draft” (英語) (2016年9月13日). 2025年7月29日閲覧。
^ ^a ^b “Can I use Content Security Policy?” (英語). Fyrd. 2025年7月29日閲覧。
^ 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.”
^ “Content Security Policy 1.0” (英語). W3C. 2025年7月29日閲覧。
^ “Content Security Policy Level 3” (英語). W3C. 2025年7月29日閲覧。
^ “HTML META element” (英語). Content Security Policy Level 2. W3C. 2025年7月29日閲覧。
^ “ngCsp directive” (英語). AngularJS. 2025年7月29日閲覧。
^ “Chrome 25 Beta: Content Security Policy and Shadow DOM” (英語). Google (2013年1月14日). 2025年7月29日閲覧。
^ “Content Security Policy 1.0 lands in Firefox Aurora” (英語). Mozilla Foundation (2013年5月29日). 2025年7月29日閲覧。
^ “RapidRelease/Calendar” (英語). Mozilla Foundation (2013年5月29日). 2025年7月29日閲覧。
^ “Bug 96765 - Implement the "Content-Security-Policy" header” (英語). WebKit (2012年10月31日). 2025年7月29日閲覧。
^ “Content Security Policy (CSP)” (英語). Microsoft. 2025年7月29日閲覧。
^ “New Chromium security features, June 2011” (英語). Google (2011年6月14日). 2025年7月29日閲覧。
^ “Introducing Content Security Policy” (英語). Mozilla Foundation. 2025年7月29日閲覧。
^ “Defense in Depth: Locking Down Mash-Ups with HTML5 Sandbox” (英語). Windows Internet Explorer Engineering Team. 2025年7月29日閲覧。
^ “CSP 2015” (英語). XSS Jigsaw (2015年11月23日). 2015年12月20日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
^ Lekies, Sebastian. “Collection of CSP bypasses” (英語). 2025年7月29日閲覧。
^ “An Abusive Relationship with AngularJS” (英語) (2015年12月12日). 2025年7月29日閲覧。
^ OWASP (2017-05-25) (英語), AppSec EU 2017 Don't Trust The DOM: Bypassing XSS Mitigations Via Script Gadgets by Sebastian Lekies 2017年6月5日閲覧。
^ West, Mike (2012年6月15日). “An Introduction to Content Security Policy” (英語). HTML5 Rocks. 2025年7月29日閲覧。
^ “Content Security Policy Level 3” (英語). www.w3.org. 2025年7月29日閲覧。
^ “CSP: report-to - HTTP | MDN” (英語). developer.mozilla.org. 2025年7月29日閲覧。
^ 例えば、Djangoでは、CSPレシーバーがdjango-securityモジュールで利用可能である。
^ “Flaring The Blue Team - When You Confuse Them You Lose Them” (英語). Secjuice (2018年11月4日). 2025年7月29日閲覧。
^ “CSP Processing Model” (英語) (2012年11月15日). 2025年7月29日閲覧。
^ “CSP 1.1: Add non-normative language for extensions.” (英語). GitHub w3c webappsec. GitHub (2014年2月27日). 2025年7月29日閲覧。
^ “Bug 866522 - Bookmarklets affected by CSP” (英語). Bugzilla. Mozilla (2013年4月28日). 2025年7月29日閲覧。
^ “Subverting CSP policies for browser add-ons (extensions).” (英語) (2013年9月25日). 2025年7月29日閲覧。
^ “Re: [CSP Request to amend bookmarklet/extensions sentence in CSP1.1]” (英語) (2014年8月3日). 2025年7月29日閲覧。
^ ^a ^b “Web Application Security Working Group” (英語). GitHub. 2025年7月29日閲覧。
^ “Noscript security suite addon for Firefox” (英語). addons.mozilla.org. 2025年7月29日閲覧。
^ “The NoScript Firefox extension — Official site” (英語). noscript.net. 2025年7月29日閲覧。
^ “HTTP Switchboard for Opera” (英語). addons.opera.com. 2025年7月29日閲覧。

外部リンク

[fn1-21] This behavior can be disabled globally by a special 'unsafe-inline' statement

[fn2-22] Trusted inline <script> and <style> blocks can be individually allowlisted in the CSP using nonce or hash statements.

[fn3-23] This behavior can be disabled globally by a special 'unsafe-eval' statement

[fn4-24] For example, AngularJS requires only one initialization flag to be switched into the CSP-compatible mode—<html ng-app ng-csp>

[Stamm_2009-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.”

[CSPstatus-2] “State of the draft” (英語) (2016年9月13日). 2025年7月29日閲覧。

[caniuse-3] “Can I use Content Security Policy?” (英語). Fyrd. 2025年7月29日閲覧。

[Hansen_2009-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日閲覧。

[25] West, Mike (2012年6月15日). “An Introduction to Content Security Policy” (英語). HTML5 Rocks. 2025年7月29日閲覧。

[26] “Content Security Policy Level 3” (英語). www.w3.org. 2025年7月29日閲覧。

[27] “CSP: report-to - HTTP | MDN” (英語). developer.mozilla.org. 2025年7月29日閲覧。

[28] 例えば、Djangoでは、CSPレシーバーがdjango-securityモジュールで利用可能である。

[29] “Flaring The Blue Team - When You Confuse Them You Lose Them” (英語). Secjuice (2018年11月4日). 2025年7月29日閲覧。

[CSPprocessing-30] “CSP Processing Model” (英語) (2012年11月15日). 2025年7月29日閲覧。

[31] “CSP 1.1: Add non-normative language for extensions.” (英語). GitHub w3c webappsec. GitHub (2014年2月27日). 2025年7月29日閲覧。

[32] “Bug 866522 - Bookmarklets affected by CSP” (英語). Bugzilla. Mozilla (2013年4月28日). 2025年7月29日閲覧。

[CSPBug23357-33] “Subverting CSP policies for browser add-ons (extensions).” (英語) (2013年9月25日). 2025年7月29日閲覧。

[34] “Re: [CSP Request to amend bookmarklet/extensions sentence in CSP1.1]” (英語) (2014年8月3日). 2025年7月29日閲覧。

[WASWG-35] “Web Application Security Working Group” (英語). GitHub. 2025年7月29日閲覧。

[36] “Noscript security suite addon for Firefox” (英語). addons.mozilla.org. 2025年7月29日閲覧。

[37] “The NoScript Firefox extension — Official site” (英語). noscript.net. 2025年7月29日閲覧。

[38] “HTTP Switchboard for Opera” (英語). addons.opera.com. 2025年7月29日閲覧。

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[注釈 1]

[注釈 2]

[注釈 3]

[注釈 4]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

表話編歴脆弱性、攻撃手法、エクスプロイト
クロスサイト攻撃	クロスサイトリクエストフォージェリ (CSRF) クロスサイトスクリプティング (XSS) クロスサイト・クッキングクロスサイトトレーシングクロスゾーンスクリプティング（英語版）
インジェクション (CWE-74)	OSコマンドインジェクション (CWE-78) クロスサイトスクリプティング (XSS) (CWE-79) SQLインジェクション (CWE-89) LDAPインジェクション (CWE-90) コードインジェクション (CWE-94) HTTPヘッダ・インジェクション (CWE-113) HTTPレスポンススプリッティング（英語版） (CWE-113) 書式文字列攻撃 (CWE-134) プロンプトインジェクション
スプーフィング攻撃	DNSスプーフィング IPスプーフィング ARPスプーフィングクリックジャッキング (CAPEC-103) リファラスプーフィング（英語版） Eメールスプーフィング（英語版）フィッシング (CAPEC-98) ファーミング (CAPEC-89)
セッションハイジャック関連	セッションフィクセーション (CWE-384, CAPEC-61) セッションポイズニング（英語版） TCPシーケンス番号予測攻撃クッキーモンスター攻撃（英語版）
DoS攻撃	SYN flood ICMP echoフラッド Smurf攻撃 UDPフラッド攻撃スローロリス (DOS攻撃ツール) メールボムクリアチャネル評価攻撃（英語版）
サイドチャネル攻撃	コールドブート攻撃（英語版） Meltdown Spectre Lazy FP state restore（英語版） TLBleed（英語版）
不適切な入力確認 (CWE-20)	バッファオーバーフロー (CWE-119、120、121等) Return-to-libc攻撃ディレクトリトラバーサル (CWE-22)
未分類	中間者攻撃 (CAPEC-94) MITB攻撃 MOTS攻撃（英語版） Off-by-oneエラー (CWE-193) ファイルインクルード脆弱性（英語版） Mass Assignment脆弱性（英語版）ダングリングポインタ（英語版） DNSリバインディング in-sessionフィッシング（英語版）クッキースタッフィング（英語版）悪魔の双子攻撃 IDNホモグラフ攻撃スナーフィング（英語版） JITスプレーイング（英語版）リプレイ攻撃誕生日攻撃 CRIME KRACK Intel ME（英語版）の脆弱性
対策	Outbound Port 25 Blocking（OP25B） Content Security Policy（CSP）コンテントスニッフィング（英語版） HTTP Strict Transport Security (HSTS) ファイアウォール侵入防止システム (IPS) 侵入検知システム (IDS) Web Application Firewall (WAF) Wi-Fi Protected Access セキュリティ・バイ・デザイン（SBD）
関連項目	マルウェアセキュリティホールクラッキング脆弱性情報データベースブラウザクラッシャーシェルコード Metasploit Sshnuke Nikto Web Scanner（英語版） OWASP（英語版） w3af（英語版）隠れ通信路（英語版）

Content Security Policyとは？ わかりやすく解説