CSP（コンテンツセキュリティポリシー）のセキュリティ診断10項目

コンテンツセキュリティポリシー（CSP）の診断項目一覧（10項目）

XSS（クロスサイトスクリプティング）の被害を抑えるCSPの設定内容を確認します。各項目名から、意味・診断基準・リスク・具体的な対策を解説したページへ移動できます。

CSP（コンテンツセキュリティポリシー）の診断とは

CSP（コンテンツセキュリティポリシー）の診断は、ページがどこからスクリプト・スタイル・画像などを読み込み、どのような実行を許すかをブラウザに宣言させる設定が、実際に役立つ形で入っているかを確かめるものです。セキュリティ診断127項目のうち、CSPの設定内容に関する10項目がこの分類に入ります。

CSPは、XSS（クロスサイトスクリプティング）で攻撃者のスクリプトが紛れ込んでも、許可していない配信元からの読込やインライン実行をブラウザに拒否させる仕組みです。出力時のエスケープなどの根本対策の代わりではなく、対策が漏れた場合に被害を抑える「最後の防御線」と位置づけられます。

注意したいのは、「CSPのヘッダーがある」ことと「CSPが効いている」ことは別だという点です。upgrade-insecure-requests だけのCSPはスクリプトを何も制限しませんし、スクリプトで 'unsafe-inline' を許可したCSPは典型的な script タグの注入を止められません。Report-Onlyのヘッダーは違反を報告するだけで遮断しません。そのためこの分類では、CSPの有無だけでなく、届け方・中身の厳しさ・抜けやすいディレクティブを項目ごとに分けて確認します。

10項目の全体像（4つのグループ）

この分類の10項目は、大きく4つのグループに分けて考えると整理しやすくなります。

CSPの配信方法には、強制ヘッダー・Report-Onlyヘッダー・meta要素の3通りがあり、すべての機能が使えて攻撃を止められるのは強制ヘッダーだけです。meta要素では frame-ancestors・report-uri・sandbox が使えず、Report-Onlyは違反を報告するだけです。このため「CSPの基幹ディレクティブ」と「CSP違反の報告先」は、強制CSPヘッダーがない場合は対象外となり、届け方の問題は「CSPがレスポンスヘッダーで強制されている」で評価されます。

優先して確認すべき項目

この分類に重大度「最重要（critical）」の項目はありませんが、10項目のうち7項目が「重要（high）」です。CSPの効果そのものを左右する順に確認します。

1. CSPの有無と強制：「Content Security Policy」と「CSPがレスポンスヘッダーで強制されている」が土台です。CSPがあっても script-src も default-src もなければスクリプトは無制限で、Report-Onlyやmetaだけでは防御効果が限られます。
2. スクリプトの 'unsafe-inline'：XSSの典型的な注入はインラインのスクリプトです。スクリプトで 'unsafe-inline' が有効なCSPは、注入された script 要素や onerror などのイベントハンドラーをそのまま実行させます。最も優先して外すべき設定です。
3. 'unsafe-eval'：eval() や new Function()、文字列を渡した setTimeout() などを許可します。nonce・hash・'strict-dynamic' があっても無効化されないため、削除が必要です。
4. 過剰なワイルドカードとHTTP配信元：スクリプトに *・https:・data: を許すと、攻撃者が用意したHTTPSサイトのスクリプトも読み込めます。平文HTTPの配信元は、通信経路上で書き換えられたコードが入り込む余地を残します。
5. 基幹ディレクティブ：object-src・base-uri・form-action・frame-ancestors の4つは、default-src を厳しくしても抜けが生じます。推奨の最小構成は object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'self' です。

「中（medium）」の「CSPのdefault-src」は、明示していない種類のリソース（画像・通信先・フォントなど）が無制限になるのを防ぐ既定値です。「低（low）」の「CSP違反の報告先」と「Trusted Typesの適用」は、直接の脆弱性というより運用監視の品質や、DOM XSSへの追加の防御にかかわる項目で、基本の設定がそろった後に進めます。

直すときの進め方と注意点

CSPは、いきなり厳しい値を強制すると、許可していない外部タグや地図・動画が止まり、表示が崩れることがあります。次の順で段階的に進めるのが安全です。

• 棚卸しから始める：ページが読み込んでいる外部スクリプト・スタイル・画像・通信先と、インラインのスクリプトやonclickなどのイベントハンドラー属性を洗い出します。
• Report-Onlyで試す：まずContent-Security-Policy-Report-Onlyで配信し、数週間違反を確認します。報告先（report-uri・report-to）を設定しておくと、違反の内容を把握しやすくなります。report-to を使う場合はReporting-Endpointsヘッダーも必要です。
• 強制ヘッダーに切り替える：違反がなくなったら、同じ値をContent-Security-Policyレスポンスヘッダーで配信します。ヘッダーとmetaの両方に書くと両方が適用され意図より厳しくなることがあるため、ヘッダーへ移行したらmetaは削除して一本化します。
• インラインを外していく：onclick などの属性は外部の .js ファイルに移して addEventListener で登録し、残るインラインスクリプトはnonceやhashで許可します。出力後のHTMLを書き換えて全scriptタグに一律にnonceを付ける方式は、注入されたscriptにもnonceが付くため避けます。
• 値の書き方に注意する：'none' は単独で書いたときだけ有効で、object-src 'none' https: のように並べると https の任意オリジンを許可してしまいます。http:// の配信元は https:// に書き換えても、HTTPS配信されているリソースの読込は維持されます。
• Trusted Typesは最後に検討する：require-trusted-types-for 'script' は、外部ウィジェットが文字列でシンクを使うと動かなくなることがあります。Report-Onlyで違反箇所を洗い出してから強制します。

自治体・公共機関のサイトで特に注意すること

自治体や公共機関のサイトは、CMSのテンプレートや外部の地図・動画・アクセス解析タグなどを組み合わせて作られていることが多く、CSPの導入でつまずきやすい傾向があります。よくある状況として、次のようなものがあります。

• CMSのプラグインやテーマがインラインスクリプトを多用しており、default-src 'self' 'unsafe-inline' https: のような、ヘッダーはあっても実質的にスクリプトを制限しない値になっている。
• upgrade-insecure-requests だけのCSPや、frame-ancestors だけのCSPで「CSPは導入済み」と扱われている。
• 外部の電子申請・決済サービスへ送信するフォームがあり、form-action 'self' を入れると送信が止まる。必要な送信先オリジンを form-action に追加する必要があります。
• 自前サーバーから画像・CSS・JSを配信している場合、default-src 'self' が導入しやすい現実的な初期値になりますが、外部の画像・Webフォント・地図タイル・動画埋め込みは個別に許可が要ります。
• 検索結果の表示、多言語切替、地図やイベントカレンダーの埋め込みなど、クライアント側でHTMLを組み立てる機能が多く、DOM XSSの入口になりやすい。

CMSを使っている場合は、サーバー設定でReport-Onlyから始め、管理画面は別ポリシーにするのが安全です。

よくある質問（FAQ）

ほかの分類の診断項目

• 通信の暗号化（HTTPS・TLS・HSTS）13項目
• セキュリティヘッダー13項目
• CORS（クロスオリジン設定）5項目
• Cookie・セッション管理12項目
• HTML・JavaScript・外部資産14項目
• HTMLの基本衛生7項目
• フォーム・パスワード入力9項目
• 認証・アクセス制御7項目
• DNS・メールのなりすまし対策10項目
• 公開ファイル・情報露出19項目
• HTTP応答・エラー処理6項目
• 巡回範囲・サプライチェーン2項目