先に読むと理解しやすい記事：HTTP・HTTPS / URL・ドメイン・オリジン

ページが実行できるコードなどをブラウザへ伝える

CSPはContent Security Policyの略で、ページが読み込めるスクリプトや画像などの制限をブラウザへ伝える仕組みです。サーバーはContent-Security-Policyレスポンスヘッダーなどで方針を指定します。

たとえばコメントがHTMLへ混入する不備があっても、許可していないスクリプトの実行をブラウザに拒否させる防御を追加できます。ただしCSPは入力処理の不備を直すものではないため、出力先に合うエスケープや無害化と組み合わせます。

参照：出典 s1

何を制限するかをディレクティブで指定する

CSPの一つ一つの指示をディレクティブと呼びます。script-srcはスクリプト、img-srcは画像、connect-srcはfetchなどの通信先を指定します。default-srcは、個別指定がない取得系ディレクティブの代わりの方針です。

次の例では、原則同一オリジンから取得し、スクリプトも同一オリジンに限定します。object-srcでプラグインなどの埋め込みを禁止し、base-uriで基準URLの指定を禁止します。frame-ancestorsは自分のページを他のページへ埋め込める相手で、この例では禁止です。これらすべてにdefault-srcが代わりに適用されるわけではありません。

説明用の通信例・設定例・擬似コード

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'none'; frame-ancestors 'none'

参照：出典 s1

nonceで実行を認めるスクリプトを指定する

nonceは、そのレスポンスのために生成する推測しにくいランダムな値です。CSPのscript-srcへnonceの許可を書き、サーバーが実行を認めるscript要素にも同じ値を付けます。ブラウザは値の一致などを確認して実行を判断します。

固定値や使い回しにすると、攻撃者が値を知って自分のscript要素へ付けられるおそれがあります。次のRANDOM_PER_RESPONSEは説明上の記号で、本番にそのまま書く値ではありません。攻撃者が挿入した要素へ、処理の途中で一律にnonceを付けないことも重要です。

説明用の通信例・設定例・擬似コード

Content-Security-Policy: script-src 'nonce-RANDOM_PER_RESPONSE'; object-src 'none'; base-uri 'none'

<script nonce="RANDOM_PER_RESPONSE">
  console.log('approved script');
</script>

参照：出典 s1 / 出典 s2

ハッシュは実行を認めるコードそのものに対応する

ハッシュによる許可では、実行を認めるスクリプトの内容から計算した値を方針へ登録します。ブラウザが実際の内容と照合するため、登録後に改行や空白を変えても一致しなくなる場合があります。静的なページでも使えます。

nonceはレスポンスごとの値で許可し、ハッシュは特定の内容で許可する点が違います。unsafe-inlineでインラインコードを広く許可したり、unsafe-evalで文字列のコード実行を許したりすると、防御が弱くなるため、必要性と代替方法を確認します。

参照：出典 s1 / 出典 s2

許可した場所にある危険なコードまでは安全にしない

仮定の例として、同一オリジンに利用者が任意のJavaScriptファイルを公開できる場所があり、script-srcにselfを許可するとします。攻撃者がその場所へコードを置き、別のHTML挿入の不備から読み込ませると、許可条件を満たして実行されるおそれがあります。

許可元を列挙するだけで万能とは考えません。nonceやハッシュを使う厳格な方針を検討しつつ、HTMLの扱いとファイル配信を直します。CSPがあっても、サーバー側の認可不備や、許可済みスクリプト自体の不正動作は別に対策します。

参照：出典 s1 / 出典 s2

Report-Onlyは観測用で、実行を止めない

Content-Security-Policy-Report-Onlyでは、方針に違反する処理を実際には止めず、コンソールや設定した送信先へ報告する運用ができます。正規の機能を壊さないか確認するために使い、確認後に強制するヘッダーへ切り替えます。

レポートの送信先も設定が必要です。報告にはページURLなどが含まれ得るため、個人情報の扱いと保存を考えます。報告が届かない場合でも、違反が起きている可能性は残ります。ブラウザや送信の制約も考慮します。

参照：出典 s1 / 出典 s2

正規機能と拒否動作の両方を確認する

確認問題：Report-Onlyで警告が出たスクリプトは実行されないでしょうか。答えは違います。その方針は観測用で、強制するCSPとは異なります。

自分の検証環境で、必要な画面や外部連携が動くか、許可していないコードが拒否されるかを確認します。meta要素の指定には対応しない機能もあるため、必要な方針をヘッダーで配信できるかも確認します。

参照：出典 s1 / 出典 s2

出典・確認範囲

  1. [s1] Content Security Policy (CSP)MDN / 確認日 2026-11-03
  2. [s2] Content Security Policy Cheat SheetOWASP / 確認日 2026-11-03
未確認事項・限界

通信例・設定例・被害の例は、仕組みを理解するための仮定です。特定の製品で発生した事件を示すものではありません。ブラウザやサービス固有の設定は、利用する環境の公式資料でも確認してください。