Content Security Policy(CSP)設定値を完全解説:主要ディレクティブ早見表

Content Security Policy(CSP)は「このページが読み込んでいい外部リソース」を宣言し、XSSなどの被害を抑えるための重要な防御策です。
本記事では、directive value; の基本構文や self/none、unsafe-inline/unsafe-eval、nonce・hashの使いどころを整理し、主要ディレクティブを早見表でまとめ、CSPの設定値について詳しく解説します。
CSPにどのような値を設定しようか悩まれている方は是非参考にしてみてください。
目次
- そもそもContent Security Policy(CSP)とは?
- Content Security Policy(CSP)の書き方・構文まとめ(設定値の基本)
- 主要ディレクティブ早見表(これだけ覚えればOK)
- まとめ
そもそもContent Security Policy(CSP)とは?
Content Security Policy(CSP)とは、Webページが読み込めるスクリプトや画像、通信先などの範囲をブラウザに宣言し、不正なコード実行(XSSなど)を防ぐためのセキュリティ設定です。
そもそもContent Security Policy(CSP)とは何か知りたい方は、別でCSPについて詳しく解説している記事があるので、下のリンクを参照してください。
参考記事:CSP(Content Security Policy)とは?XSS対策に欠かせない理由と注意点
Content Security Policy(CSP)の書き方・構文まとめ(設定値の基本)
まずは基本的なCSPの書き方と設定値を知りましょう。
設定の書き方:directive value, directive valueの基本形
CSPの設定の書き方は、directive value; を基本単位としてセミコロンで連結し、どの種類のリソースをどこから読み込めるかを明示します。
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com;
ディレクティブごとに許可範囲を絞ることで、想定外の外部スクリプト読み込みなどによる脆弱性の悪用を回避しやすくなります。不要に許可を広げず、まずは最小の例から調整すると安全です。
値の種類:self / none / スキーム / ホスト / ワイルドカード
CSPの値は「どこから読み込むか」を表し、設定の書き方次第で防御力が変わります。
self は同一オリジンのみ許可、none は一切許可しません。
https: のようにスキームで絞ると安全な通信だけに限定でき、https://cdn.example.comのようにホストを指定すれば必要な外部だけ許可できます。
アスタリスクや広すぎるワイルドカードは許可範囲が膨らみ、脆弱性の回避効果が落ちるため不要な指定は避けます。
よく出るキーワード:unsafe-inline / unsafe-eval の意味と注意
unsafe-inlineはインラインの<script>やonclickなどを許可し、unsafe-eval はeval()やnew Function()のような文字列からの実行を許可します。
どちらもCSPの防御を弱め、XSSなどの脆弱性が悪用される余地を増やすため、基本的に不要な設定です。やむを得ず使う場合も、影響範囲を理解したうえで段階的に回避策(nonce/hashやコード修正)へ移行できる書き方にしておくと安全です。
nonce / hash(sha256等)の役割と使いどころ
nonceとhashは、インラインスクリプトや<style>を「全部許可」せずに、必要なものだけ通すための仕組みです。
nonceはリクエストごとに生成したランダム値をCSPとタグ両方に付けて一致したものだけ実行させる書き方で、XSSなどの脆弱性の悪用を回避しやすくなります。
hash(sha256等)は「この内容のインラインコードだけ実行していい」とブラウザに許可するための内容一致チェックです。ページ内のインラインコードが完全に同じ文字列なら実行され、1文字でも違えばブロックされるので、'unsafe-inline' を使わずに脆弱性(XSS)リスクを下げられます。
主要ディレクティブ早見表(これだけ覚えればOK)
| ディレクティブ | 何を制御する? |
|---|---|
default-src | 未指定の各種リソースのデフォルト許可元 |
script-src | JavaScript(<script>の取得・実行) |
style-src | CSS(外部CSS/<style>/インライン) |
img-src | 画像(<img>など) |
connect-src | 通信(fetch/XHR/EventSource/WebSocketなど) |
font-src | フォントの読み込み元 |
media-src | 動画・音声の読み込み元 |
frame-src | iframeで読み込む先(埋め込み先) |
frame-ancestors | 自サイトをiframeで埋め込める相手(クリックジャッキング対策) |
default-src:デフォルトの土台(最初に決める)
default-srcはCSPの「デフォルトの土台」で、個別にscript-srcやimg-srcなどを設定していない場合に、どの送信元を許可するかを一括で決めます。
最初にここを絞っておくと、設定漏れがあっても許可範囲が広がりにくく、安全な初期状態を作れます。逆にdefault-src *のように広くすると、他の制御も効きにくくなりがちです。
script-src:JavaScript制御の要(nonce/hash/strict-dynamic含む)
script-srcはJavaScriptの読み込み元と実行可否を決めるCSPの要です。
基本は**selfや必要なドメインだけを許可し、インライン実行を広く許すunsafe-inlineは避けます**。代わりにnonce(都度生成する値)やhash(内容の指紋)で「許可したものだけ」を実行させます。
strict-dynamicはnonce/hashで信頼した起点から動的に追加されるスクリプトも許可できます。
style-src:CSSの許可(style要素/外部CSS/インラインの扱い)
style-srcはCSSの読み込み元を制御し、外部CSSファイルだけでなく<style>要素やstyle=""などインラインの扱いも決めます。
基本は**selfや必要なドメインだけを許可し、インラインを広く通す'unsafe-inline'は極力避けます**。必要な場合はnonceやhashで特定の<style>だけ許可し、安全に運用します。
img-src:画像の許可(data: の扱いも含む)
img-srcは画像をどこから読み込めるかを制御します。selfや必要なCDNだけを許可し、想定外の外部画像読み込みを防ぎます。
data:はData URL(HTML内に埋め込む画像)を許可する指定で、アイコンや小さな画像で使われますが、許可すると範囲が広がるため本当に必要な場合だけ追加します。
connect-src:API通信(fetch/XHR/WebSocket)の許可
connect-srcは、ブラウザから外部へ送る通信先を制御します。
対象はfetch/XMLHttpRequestによるAPI呼び出し、EventSource、WebSocket(wss:)などで、許可していないドメインへの通信はブロックされます。
APIのホストやWebSocketの接続先を必要最小限に限定すると、情報送信先の逸脱を防ぎやすくなります。
font-src / media-src:フォント・動画音声の許可
font-srcはWebフォントの読み込み元、media-srcは動画・音声(<video>/<audio>)の取得元を制御します。
自サイト配信ならselfで足りますが、外部CDNや配信サービスを使う場合はそのドメインを追加しないと表示・再生が失敗します。
許可先を必要最小限に絞ることが安全です。
frame-src / frame-ancestors:埋め込み(iframe)とクリックジャッキング対策
frame-srcは「自分のページがiframeで読み込む先」を制御し、信頼できる埋め込み先だけ許可できます。
一方、frame-ancestorsは「自分のサイトがどのサイトにiframeで埋め込まれてよいか」を制御し、クリックジャッキング対策の中心です。
基本はnone(埋め込み禁止)かselfで絞り、必要な相手だけ追加します。
まとめ
Content Security Policy(CSP)には、用途に応じて様々な設定値を設定できます。
適切にリソースを許可することで、セキュリティを高めていきましょう。





