- ホーム
- 記事一覧
- 情報セキュリティの記事一覧
- Content Security Policy(CSP)とは?役割と設定・確認の4ステップ
Content Security Policy(CSP)とは?役割と設定・確認の4ステップ

「CSPが設定されていない」と指摘されても、何を頼めばよいか迷うことがあります。Content Security Policy(CSP)は、スクリプトなどの読み込みや実行を許可する条件を、ブラウザに伝える仕組みです。まず現状を確かめ、制作・保守の担当者(以下、担当者)と共有してください。設定は、動作を止めずに試してから適用します。
- ① CSPは、スクリプト(ページ上で動くプログラム)などの読み込みや実行を許可する条件を、ブラウザに伝える仕組みです。
- ② まず、自社サイトにCSPが設定されているかを確かめます。開発者ツール(ブラウザでページの中身を調べる機能)を使います。
- ③ スクリプトや、ページがデータを送る先(送信先)を確かめ、Report-Only(止めずに報告だけ受け取る方式)で試します。確認後に適用し、外部ツールを足したり変えたりしたときは見直します。
出典:MDN:CSPの解説
Content Security Policy(CSP)とは?役割をわかりやすく解説
CSP(コンテンツセキュリティポリシー)は、スクリプトなどの読み込みや実行を許可する条件を、ブラウザに伝える仕組みです。制限を適用する(実際に止める設定を有効にする)と、条件に合わない読み込みや実行をブラウザが止めます。
出典:W3Cの仕様(Content Security Policy Level 3)

CSPで防ぎやすくなること
主な役割は、XSS(ページ上で不正なスクリプトを動かす攻撃)の被害を減らすことです。攻撃者がスクリプトを差し込んでも、許可条件に合わなければブラウザが実行を止めます。
CSPの設定では、スクリプトの配信元(スクリプトを置いている場所)や、実行を許可する条件などを決めます。ページで動かしてよいものを、サイト側からブラウザへ伝える考え方です。
出典:MDN:CSPの解説
CSPだけでは防げないこと
CSPは、ほかの対策に重ねて使う「2枚目の守り」です。システムの弱点である脆弱性そのものを直す仕組みではありません。
許可したスクリプトの配信元が改ざんされた場合は、CSPだけで防げるとは限りません。配信元を許可する設定では、ブラウザはその配信元から届いたスクリプトを、条件に合うものとして扱うためです。サーバー(ページを届けるコンピューター)側の弱点にも、別の対策が必要です。担当者には、CSPの設定と弱点の修正を合わせて相談してください。
出典:OWASP:Content Security Policy Cheat Sheet
CSPの2つの書き方
基本は、レスポンスヘッダー(サーバーがページと一緒に送る設定の情報)で渡す方法です。もう1つは、HTML(ページを作るためのコード)の中に書く方法です。こちらでは、metaタグという設定用の記述を使います。
ただし、metaタグではすべての機能を使えません。Report-Only(止めずに報告だけ受け取る方式)や、自社のページを埋め込んで表示できるサイトの指定などは使えないためです。また、ページのコードの中でmetaタグより前に書かれた部分には、そのCSPが効きません。
設定する場所だけで判断せず、必要な機能を使えるか担当者に確認してください。
出典:W3C:meta要素でのCSPの指定、MDN:CSPの解説
【関連記事】HTMLのセキュリティ対策は万全?初心者でもできる脆弱性対策15選【決定版】
自社サイトのCSPを確認する方法
自社サイトのCSPは、ブラウザの開発者ツールで確かめられます。設定の有無だけでなく、制限を適用しているかも確認します。
開発者ツールでレスポンスヘッダーを見る
まず、調べたいページで次の操作を行います。
- ブラウザの開発者ツールを開きます。
- 通信の一覧を表示し、ページを読み込み直します。例えばChromeでは「Network」に当たります。
- 調べたいページの通信を選び、サーバーから届いた設定の情報を見ます。例えば「Headers」タブの「Response headers」です。
画面の名前は、Chromeの版などによって違うことがあります。操作が分からない場合は、担当者に確認を頼めます。
設定の情報では、次の2つを探してください。
| 表示される名前 | 意味 |
|---|---|
| Content-Security-Policy | 許可条件に合わない読み込みや実行を止めます。 |
| Content-Security-Policy-Report-Only | 許可条件に合わない動作を止めず、報告だけを行います。 |
両方がある場合は、それぞれの設定が働きます。Report-Onlyを追加しても、すでに適用している制限は解除されません。
出典:MDN:Content-Security-Policy-Report-Only
これらが見つからない場合も、すぐに未設定とは判断しません。HTML内にCSP用のmetaタグがないか、担当者に確かめてもらいます。
コンソールの違反のメッセージを見る
開発者ツールの中にあるコンソール(動作中の問題などを表示する画面)では、CSPに関するメッセージを確認できます。許可条件に合わない動作を「違反」と呼び、その内容もここに表示されます。表示された場合は、どのページで何を操作したかも担当者に伝えてください。
担当者は、何が許可条件に合わなかったかを調べます。メッセージが出たことだけを理由に、許可する範囲を広げないことが大切です。
CSP Evaluatorで設定を評価する
CSP Evaluatorは、XSSへの防御を弱めるCSPの設定がないかを調べる公開ツールです。結果の読み取りや修正方針は、担当者に相談してください。
SiteScanでCSPの有無を確認する
株式会社Spider Labsが提供するSiteScanは、サイトにCSPがあるかを確認します。Report-Onlyの設定しかない場合は「CSPがない」と判定し、metaタグで書いたCSPは「ある」と判定します。CSPの内容は、担当者に確認してもらってください。CSPがあるだけで、サイトが安全とは限りません。
CSPの設定の進め方4ステップ
CSPの設定方法の基本は、動作を止めずに試してから適用することです。担当者が設定し、Web担当者は判断に使う材料をそろえます。

ステップ1:スクリプトやデータの送信先を確認する
まず、ページで使うスクリプトと、データの送信先を一覧にします。外部ツールのタグ(ツールを動かすためにページへ入れるコード)も対象です。自社のスクリプトや、HTMLに直接書いた処理も担当者が確認します。
画像をどこから読み込むか、フォームに入力した情報をどこへ送るかも、担当者と一緒に確かめてください。Web担当者は、ツールの用途と必要性、社内の管理担当を整理します。
SiteScanは、ブラウザで読み込まれる外部ツールやJavaScript、タグを一覧にします。JavaScriptは、スクリプトを書くための言語です。タグのデータの送信先も確認でき、許可条件を考える材料になります。
ログインが必要なページや、公開していないページも調べる場合は、設置の条件があります。GTM(Googleタグマネージャー。タグをまとめて管理する仕組み)経由で、SiteScanのタグを設置する必要があります。
ステップ2:Report-Onlyで試す
担当者は、Report-Only(止めずに報告だけ受け取る方式)で設定の影響を調べます。始める前に、担当者が報告を受け取る先(報告先)を用意し、実際に報告が届くか確かめます。
報告先を指定しないと、報告は外部に送られません。Chromeなどでは、開発者ツールのコンソールに表示されるだけです。試す期間と確認する操作は、Web担当者と担当者で決めます。
出典:MDN:Content-Security-Policy-Report-Only
ステップ3:違反の報告を見て、許可条件を調整する
担当者は報告を見て、どのページで何が条件に合わなかったかを調べます。報告に出たスクリプトの配信元などについて、必要性と信頼性を確認します。
報告に出たものを、すべて許可する進め方は避けてください。必要なツールかどうかを社内で判断し、担当者が条件を調整します。直した後は、もう一度試して動作を確かめます。
ステップ4:公開中のサイトで適用する
必要な機能が動くことを確認できたら、担当者が公開中のサイトに制限を適用します。適用後もフォーム送信や計測を確認します。問題があれば、担当者に条件を見直してもらってください。
担当者に依頼するときに押さえること
CSPは、項目ごとに許可の条件を書きます。次の項目の役割を押さえておくと、担当者に確認したい内容を伝えやすくなります。
表A:主な設定項目とWeb担当者向けの意味
| 設定項目 | 何を決めるか |
|---|---|
| default-src | 個別に指定していない画像やスクリプトなどの、共通の読み込み条件を決めます。すべての設定の代わりにはなりません。 |
| script-src | スクリプトの読み込みや実行を許可する条件を決めます。 |
| connect-src | スクリプトがデータを送受信できる接続先を決めます。あらゆる送信をまとめて制御する設定ではありません。 |
| form-action | フォームの送信先として許可する場所を決めます。 |
| frame-ancestors | 自社のページを埋め込んで表示できるサイトを指定します。HTML内のmetaタグでは使えません。制限を適用するCSPにこの項目があると、ブラウザはX-Frame-Options(埋め込みを制限する別の設定)を無視します。 |
| upgrade-insecure-requests | http(暗号化されていない通信)での読み込みなどを、https(暗号化された通信)に変えるよう指示します。画像などの読み込みやフォーム送信が対象です。別のサイトへページ全体を切り替えるリンクは対象外です。 |
| object-src | ブラウザの追加機能(プラグイン)など、ページに埋め込む部品の読み込みを制限します。 |
| base-uri | ページ内のリンクの基準として、HTML内に指定できるURLを制限します。 |
form-action・frame-ancestors・base-uriには、default-srcで決めた条件が及びません。また、Webの安全対策の資料を公開しているOWASPという団体には、検証基準「ASVS 5.0」があります。この基準のレベル2は、object-srcとbase-uriを'none'にするよう求めています。'none'は、何も許可しない指定です。
出典:MDN:Content-Security-Policyの設定項目、MDN:CSPの解説、OWASP ASVS 5.0:Web Frontend Security、W3C:frame-ancestorsとX-Frame-Optionsの関係
依頼するときは、設定値を自分で決めるよりも、対象や確認の担当を明確にしてください。
表B:担当者への依頼に入れる項目
| 項目 | 伝える内容 |
|---|---|
| 対象のページ | CSPを確認・適用するページを指定します。 |
| 外部ツールと配信元の一覧 | ツール名とスクリプトの配信元、データの送信先を共有します。 |
| 必要なツールと不要なツール | 社内で用途と管理担当を確認し、必要性を判断します。 |
| Report-Onlyで試す期間 | 試す期間と、その間に確認する操作を決めます。 |
| 違反の報告の受け取り方 | 報告先と、内容を確認する担当者を決めます。 |
| 適用の予定日と確認の担当者 | 適用日と、適用後の動作を確かめる担当者を決めます。 |
【関連記事】ペイメントアプリ改ざんとは?タリーズ事件から学ぶWebスキミングの手口と開発者が今すぐできる対策
CSPを設定するときの注意点
許可を広げすぎると、CSPの効果が薄れます。一方で、狭めすぎると必要なタグが動かなくなるため、適用前の調整が必要です。
'unsafe-inline'などの広い許可に頼らない
HTMLに直接書いた処理を広く許可する値に、'unsafe-inline'があります。MDN(Webの技術資料を公開しているサイト)は、CSPの効果を弱めるため使わないよう勧めています。
タグが動かない場合も、安易にこの値を足す進め方は避けてください。まず、どの処理が止まったかを担当者が調べます。
出典:MDN:CSPの解説
配信元を並べる方式と、nonce・hashを使う方式を相談する
許可するスクリプトの配信元を並べる方法は、正しく作るのにも、保守にも手間がかかります。ほかに、nonce(ページを送るたびに作る、推測されにくい使い捨ての値)を使う方法があります。hash(スクリプトの中身から計算する値)を使う方法もあります。どちらも、許可するスクリプトを1つずつ見分けて許可する考え方です。
MDNとOWASPは、nonceやhashを使う方式を勧めています。Web担当者だけで方式を決めず、自社サイトでどう実現するか担当者と相談してください。
出典:MDN:Strict CSP、OWASP:Content Security Policy Cheat Sheet
Googleタグマネージャーなどで後から読み込まれるタグも確かめる
GTMなどから後で読み込まれるタグも、確認の対象です。最初に読み込むスクリプトだけで判断せず、操作に伴って動くタグも調べます。
広告やアクセス解析の担当者にも、必要なタグと確認する操作を共有してもらってください。担当者が、その動作を許可条件と照らし合わせます。
違反の報告先の書き方を確認する
違反の報告には、report-to(報告先を指定する項目)を使う方法が、現在の基本です。担当者は、Reporting-Endpointsという設定の情報で報告先を決めます。
以前からあるreport-uriは、今後は使わない方向の項目(非推奨)です。ただし、report-toに対応していないブラウザでも報告を送れるよう、当面は両方を書くことが勧められています。どう書くかは、対応するブラウザを踏まえて担当者が判断します。
出典:W3C:report-uriの扱い、MDN:Reporting-Endpoints
テスト環境でフォームや計測の動きを確かめる
テスト環境(公開中のサイトに影響させずに試す環境)で、主要な操作を確かめます。問い合わせフォームの送信や、広告・アクセス解析のタグの動作が確認対象です。
ステップ2〜4の、試す・調整する・制限を適用する流れを、担当者がテスト環境で確かめます。必要な機能が動くことを確認してから、公開中のサイトに適用します。
【関連記事】JavaScriptセキュリティ完全ガイド【2025年最新版】|セキュアコーディングから多層防御の考え方まで徹底解説
設定した後も確認を続ける
外部ツールを足したり変えたりすると、必要な許可条件も変わることがあります。CSPは、設定後も確認と見直しを続けます。
見直しが必要になる場面
広告タグ、アクセス解析、チャットなどを追加・変更したときは、CSPも見直します。Web担当者は、変更内容と利用目的を担当者に共有してください。
担当者が許可条件への影響を調べ、必要に応じて再び試します。使わなくなったツールがある場合も、設定を見直す材料になります。
定期的に確かめること
担当者は、違反の報告を定期的に確認します。Web担当者は、報告に出たツールの用途や必要性を社内で確かめてください。
SiteScanは、スクリプトのバージョン履歴を管理し、変更を継続して監視できます。その変更を担当者と確認し、CSPの更新が必要かを判断してください。
まとめ
CSPの設定は、まず開発者ツールで現状を確かめ、動作を止めずに試してから適用します。
| ステップ | 進めること |
|---|---|
| 1.確かめる | スクリプトやデータの送信先を一覧にし、必要性を社内で確認します。 |
| 2.試す | 報告先を用意し、Report-Onlyで影響を調べます。 |
| 3.調整する | 必要性と信頼性を確かめて許可条件を直し、もう一度試します。 |
| 4.適用する | 制限を適用し、フォームや計測などの動作を確認します。 |
外部ツールを追加・変更した後も、CSPの確認を続けてください。Web担当者が用途や変更点を共有し、担当者が設定を見直します。
よくある質問
Q1. Content Security Policy(CSP)とは何ですか?
CSPは、スクリプトなどの読み込みや実行を許可する条件を、ブラウザに伝える仕組みです。制限を適用すると、条件に合わないスクリプトなどの読み込みや実行をブラウザが止めます。
Q2. 自社サイトのCSPは、どこで確かめられますか?
ブラウザの開発者ツール(ページの中身を調べる機能)で確かめられます。サーバー(ページを届けるコンピューター)がページと一緒に送る設定の情報に、CSPが書かれているかを見ます。ページを作るコードの中に書かれている場合もあります。分からないときは、この2か所を制作・保守の担当者に調べてもらってください。
Q3. CSPを設定しても、広告やアクセス解析は動きますか?
許可の条件によっては、広告の表示やアクセス解析が止まることがあります。制限を適用すると、許可条件に合わない読み込みや実行をブラウザが止めるためです。そこで、まずReport-Only(動作を止めずに、条件に合わないものを報告だけする方式)で影響を調べます。制作・保守の担当者が、必要なタグ(広告やアクセス解析を動かすためにページへ入れるコード)の動きを確かめ、条件を調整してから適用します。
Q4. ページのコードの中(metaタグ)でも、CSPを設定できますか?
設定できますが、使えない機能があります。たとえば、止めずに報告だけするReport-Onlyの方式は、metaタグ(ページの設定用の記述)では使えません。基本は、ページと一緒に届く設定の情報で送る方法です。どちらで設定するかは、制作・保守の担当者と相談してください。
Q5. SiteScanにCSPの設定も任せられますか?
SiteScanは、CSPを設定する製品ではありません。サイトにCSPがあるかを確認します。ページが読み込むスクリプトや、タグ(ツールを動かすためにページへ入れるコード)がデータを送る先も一覧にします。この情報をもとに社内で必要なツールを選び、制作・保守の担当者が設定します。
- ホーム
- 記事一覧
- 情報セキュリティの記事一覧
- Content Security Policy(CSP)とは?役割と設定・確認の4ステップ










