【2026年版】Content Security Policy（CSP）とは｜設定と注意点

皆さんこんにちは。
taneCREATIVEの「ちほうタイガー」です。

この記事は、Content Security Policy（コンテンツセキュリティポリシー、CSP）の設定と注意点についてまとめたもので、2026年2月20日に執筆しています。

近年、当社の方にContent Security Policyの設定に関するご相談、ご依頼が増えてきています。

そこで、この記事では、企業のWeb担当である皆様に向けて、Content Security Policyの設定と注意点をご案内したいと思います。

少しでも皆様のお役に立てる記事にできればと思います。
どうぞよろしくお願い致します。

Content Security Policy（コンテンツセキュリティポリシー、CSP）は、Webサーバーが、HTTPレスポンスヘッダ等を通じて、ページ内で読み込み・実行・通信を許可するリソース（JavaScript、CSS、iframeなど）の取得元や実行条件、通信先を宣言し、ブラウザ側がそれを強制適用するセキュリティ制御の仕組みです。

これにより、クロスサイトスクリプティング（XSS）をはじめとするクライアントサイドのコードインジェクション攻撃において、悪意あるスクリプトの実行や不正なデータ送信を制限し、被害を軽減することが可能になります。
また、frame-ancestorsなどのディレクティブを通じてクリックジャッキング対策としても活用できます。

Content Security Policyは、設定をしていないから脆弱性があるというものではありませんが、防御を多層化するための補完的な仕組みとして有効です。

なお、CSPはLevel 2（CSP2）でnonceやform-actionなど実務上重要な機能が整理され、その後のLevel 3（CSP3）でstrict-dynamicやReporting API（report-to）が追加されました。
2026年現在、主要ブラウザは概ねCSP3相当の機能を実装していますが、特にレポーティング機構についてはブラウザ間で実装差が残っています。

XSS（クロスサイトスクリプティング）は、Webページに悪意のあるスクリプト（JavaScriptなど）を挿入し、利用者のブラウザ上で実行させる攻撃です。
実行されたスクリプトは、認証情報の窃取や不正操作の実行など、重大な被害を引き起こします。

Content Security Policyを適切に設定すると、script-srcによってスクリプトの取得元を制限でき、許可されていない外部ドメインからの不正なスクリプトの読み込みは、ブラウザによってブロックされます。

また、nonceやhashを用いることで、実行を許可するスクリプトを明示的に限定できるため、仮にページ内へ悪意あるコードが挿入された場合でも、その実行をブラウザ側で拒否させることが可能になります。

このようにCSPは、読み込み段階及び実行段階でスクリプトを制御することで、XSS攻撃の成立確率と被害規模を大幅に低減できる可能性があります。

HTMLインジェクションは、入力値の不備などを突いてページ内に任意のHTML要素を挿入する攻撃です。
必ずしもスクリプト実行を伴わない点が特徴です。

例えば、攻撃者が偽のフォームを埋め込んで利用者の認証情報を外部サイトへ送信させたり、<base>タグを書き換えてリンク先を改ざんしたり、外部通信を発生させる要素を悪用するなどの手法が典型例です。

Content Security Policyでは、form-action によるフォーム送信先の制限、connect-srcによる通信先の制御、base-uriによる基準URLの固定などを設定することで、外部への不正な情報送信や遷移を抑止できます。

このようにCSPは、スクリプトの実行を制御するだけでなく、情報送信やページ遷移といった不正な利用を制限することで、HTMLインジェクション後の二次被害を抑制できる可能性があります。

クリックジャッキングは、攻撃者が自身のWebページ上に正規サイトをiframeなどで読み込み、透明化や重ね合わせを行うことで、利用者に意図しない操作を実行させる攻撃です。
利用者は正規画面を操作していると誤認したまま、実際には攻撃者が用意したUIを通じて重要な操作を実行してしまう可能性があります。

Content Security Policyでは、frame-ancestorsディレクティブを用いることで、自サイトがどのオリジンから埋め込みを許可されるかを制限できます。
許可されていないオリジンからのiframe埋め込みはブラウザによって拒否されるため、攻撃者サイト上での表示自体が成立しません。

このようにCSPは、自サイトのコンテンツが第三者サイト上で不正に利用されることを防ぐことで、クリックジャッキングによる誤操作といった被害の発生リスクを抑制できる可能性があります。

一般的に、Webアプリケーションに対する攻撃者は、攻撃が成功するしないに関わらず、さまざまな手法を試行します。

Content Security Policyでは、ポリシー違反が発生した場合に、その内容を指定したエンドポイントへ送信する仕組みを提供しています。
report-to（Reporting API）や、互換目的で利用されるreport-uriを設定することで、違反したディレクティブやブロックされたリソース情報などを取得できます。

これにより、実際にどのような攻撃が試みられているのか、どのページでポリシー違反が発生しているのかを可視化でき、設定不備の発見や攻撃傾向の分析、早期対応につなげることができる可能性があります。

このように、CSPは予防的な制御機能に加え、検知機能も有しています。

Content Security Policy（CSP）を設定する際は、特にJavaScriptに関する不具合発生に注意が必要です。

CSPでは script-srcディレクティブによりスクリプトの読み込み元およびインラインスクリプトの実行可否を制限しますが、許可設定が不十分な場合、外部CDNのライブラリやGoogle Analyticsタグ、GTMタグ、reCAPTCHAタグ、決済スクリプトなどが読み込めず、画面表示やフォーム送信が正常に動作しなくなることがあります（外部JavaScript停止のリスク）。

また、WordPressなどではインラインスクリプトが多用されているため、unsafe-inlineを許可せず、nonceやhashも適切に設定しない場合、管理画面やブロックエディタが動作不能になる恐れもあります（インラインJavaScript停止のリスク）。
特にWordPressではインラインJavaScriptへの依存度が高いため、影響が顕在化しやすい点に注意が必要です。

Content Security Policy（CSP）では、script-src以外にも frame-src、connect-src、img-src、font-srcなどのディレクティブにより各種リソースの読み込みを制御します。

これらの設定が不十分な場合、YouTube埋め込みや決済画面などのiframeが表示されない、Ajaxや外部APIとの通信が遮断される、CDN配信の画像やトラッキングピクセルが読み込めない、Webフォントが適用されずレイアウトが崩れるといった不具合が発生することがあります。

このように、Content Security Policy（CSP）の設定は、セキュリティ強化に有効ですが、一方で、ただポリシーを宣言する作業ではなく、Webサイトのリソース読み込み、テンプレート、外部連携、監視体制を横断する変更作業であり、設定を誤るとサイトの可用性や業務運用に直結する重大な不具合を招くリスクもあります。

そのため、CSPの設定は、全体的な影響範囲の調査をした上で、Report-Onlyモードで検証しながら、段階的に適用することが重要になります。

設定費用については、Webサイトの規模も影響しますが、それ以上に外部ドメイン数やインラインJavaScriptの使用量、動的スクリプトの有無、iframeやAPI連携の数、変更頻度、テストの粒度、違反レポートの分析体制、継続運用設計などにより大きく変動します。

Content Security Policy（CSP）の設定は、セキュリティ強化に有効であり、近年CSP導入に関するご相談も増えてきています。

しかしながら、前述のようにCSPの設定は横断的な調査・設計の上で、慎重に実施をする必要がある作業であり、またWebサイトのセキュリティに対する総合的な知見が求められることから、ご契約されているWeb制作会社では対応できないと回答されるケースもあるようです。