CSPを壊さず導入する｜Report-Only・違反ログ・段階適用の手順

先に答え：本番はReport-Onlyで影響を観測してから強制する

Content Security Policy（CSP）は、JavaScript、CSS、画像、フォント、フレーム等をどこから読み込んでよいか、ブラウザーへHTTPレスポンスヘッダーで伝える仕組みです。クロスサイトスクリプティング（XSS）等への多層防御になりますが、既存サイトへ厳しい設定を突然適用すると、メニュー、フォーム、アクセス解析、動画、決済等が動かなくなることがあります。

Content-Security-Policy-Report-Only は、違反候補を報告しながら読み込みは止めないテスト用ヘッダーです。MDNは、Report-Onlyではポリシーが強制されず、指定した報告先へ違反が送られると説明しています。十分に観測・修正してから、適用する内容を Content-Security-Policy へ移します。

画像を拡大 ↗

CSPのReport-Onlyと強制ヘッダーの動作を比較した図。閉じる ×

Report-OnlyもHTTPレスポンスヘッダーで設定します。

CSPは入力値の安全化の代わりではない

CSPは、許可していないスクリプト等の実行・読み込みを抑える仕組みです。しかし入力値の検証、出力時のエスケープ、依存ライブラリの更新、認証・権限管理を不要にするものではありません。MDNも入力のサニタイズとCSPを併用する多層防御として説明しています。

まず default-src で既定の読み込み元を決め、用途ごとのディレクティブで上書きします。

画像を拡大 ↗

CSPの主要ディレクティブと対象資源の対応表。閉じる ×

default-srcは個別指定がない資源の既定値です。

導入前に読み込み元を実機能から棚卸しする

HTMLのソースだけでは、操作後に読み込むAPIやフレームを見落とします。トップページだけでなく、主要な利用動線を実際に操作し、開発者ツールのNetworkとConsoleを確認します。

1. ページ本体、CSS、JavaScript、画像、フォントの配信元を記録する。
2. メニュー、検索、フォーム、予約、ログイン、動画、地図等を操作する。
3. 本番・ステージング・管理画面で必要な元を分ける。
4. CMS、タグ管理、同意管理が動的に追加する通信を確認する。
5. 一時的なキャンペーンや古いタグを削除できないか判断する。

画像を拡大 ↗

静的な読み込みと操作後の通信を分けてCSP対象を棚卸しする図。閉じる ×

トップページを開くだけでは通信元を網羅できません。

許可リストへドメインを追加する前に、その通信が本当に必要かを確認します。ワイルドカードや https: 全体を広く許可すると壊れにくくなりますが、CSPの制限も弱くなります。

Report-Onlyで候補を置く

次は構造を示す架空例です。このまま本番へ貼る完成設定ではありません。

Reporting-Endpoints: csp-endpoint="https://example.com/csp-reports"
Content-Security-Policy-Report-Only: default-src 'self'; img-src 'self' https://images.example.com; object-src 'none'; report-to csp-endpoint

MDNは、report-to の送信先を Reporting-Endpoints ヘッダーで定義する方法を案内しています。report-uri は非推奨で report-to に置き換えられつつありますが、report-to のブラウザー対応が一様ではないため、互換性が必要な場合は両方を使う例も示しています。どの形式で受信するかは、対象ブラウザーとサーバーの受信・保管方法まで含めて決めます。

Report-Onlyは <meta> では設定できません。HTTPレスポンスヘッダーとして配信します。CDN、リバースプロキシ、Webサーバー、アプリの複数箇所で同名ヘッダーを付けると、意図しない組み合わせになるため、責任箇所を一つに決めます。

画像を拡大 ↗

example.comを使ったReporting-EndpointsとReport-Onlyヘッダーの架空例。閉じる ×

そのまま本番へ貼る完成設定ではありません。

違反ログを「必要・不要・攻撃」に分ける

受信した報告は、そのまま許可リストへ変換しません。ブラウザー拡張、利用者が挿入したコード、スキャナー、古いキャッシュ、誤設定、実際の攻撃試行が混ざる可能性があります。CSP報告自体を信頼済みの監査ログとは扱わず、再現できるか確認します。

個人情報やフォーム入力値が報告URL等へ混ざる可能性を考え、報告先のアクセス制御、保存期間、閲覧権限、ログの伏字処理を決めます。外部の報告収集サービスを使う場合は、送信内容と契約条件も確認します。

小さく強制し、戻せるようにする

観測が落ち着いても、サイト全体を一度に強制する必要はありません。影響の少ないディレクティブやページ群から始めます。

画像を拡大 ↗

Report-Onlyでの観測、ログ整理、小さな強制、監視と戻しの段階導入。閉じる ×

設定版と戻し先を記録します。

1. Report-Onlyで主要な利用動線を観測する。
2. 不要な外部読み込みとインライン処理を整理する。
3. object-src 'none' 等、影響を確認しやすい制限から検討する。
4. 低リスクのページまたは少数のトラフィックで強制する。
5. 強制中のポリシーと、次期候補のReport-Onlyを併用して観測する。
6. エラー率、フォーム完了、決済・予約、管理画面を確認する。
7. 異常時は直前のヘッダー版へ戻し、違反と機能を再現する。

通常の Content-Security-Policy とReport-Onlyを同時に送ると、前者は強制され、後者は次の候補を報告できます。ヘッダー文字列には版番号を直接持てないため、設定管理側で変更日時・担当・内容・戻し先を記録します。

nonce・hashは「固定文字列を足す」設定ではない

インラインスクリプトを安全に許可する方法としてnonceやhashがあります。MDNは、nonceはレスポンスごとに推測不能な値を生成し、CSPヘッダーと許可する script / style 要素へ同じ値を付ける方式を推奨しています。固定nonceを使い回したり、すべてのscriptへ機械的に付けたりしません。

静的HTMLではhashベースが適する場合がありますが、内容変更でhashも変わります。'unsafe-inline' を追加すると導入は容易でも、インラインJavaScriptを制限する目的を大きく損ないます。エラーを消すためだけに追加せず、テンプレートやスクリプト構成を見直します。

画像を拡大 ↗

サーバーがレスポンスごとにnonceを生成し、ブラウザーが照合する図。閉じる ×

nonceは固定文字列として設定しません。

失敗したときの分岐

そのまま使える導入メモ

対象：https://example.com/ の公開ページ
設定箇所：CDN／Webサーバー／アプリ（責任箇所：＿＿＿＿）
現行CSP：なし／あり（控え：＿＿＿＿）
Report-Only開始：＿＿＿＿
観測する機能：メニュー／検索／フォーム／動画／地図／ログイン
報告先：https://example.com/csp-reports
ログの保存期間・閲覧権限：＿＿＿＿
必要通信：＿＿＿＿
削除する不要通信：＿＿＿＿
強制開始するページ・割合：＿＿＿＿
確認指標：エラー／フォーム完了／予約・決済／管理画面
戻すヘッダー：＿＿＿＿
担当：設定＿＿＿／機能確認＿＿＿／セキュリティ判断＿＿＿

CSPの目的はConsoleの警告をゼロにすることではありません。必要な機能を保ちながら、読み込み・実行できる範囲を説明可能な大きさへ縮め、変更時に再確認できる運用を作ることです。

SITE PORTを検討するときの確認ポイント

サイト制作を依頼する場合は、画面の見た目だけでなく、この記事で扱った設定を誰が担当するか、公開後の変更や確認をどこまで依頼できるかを先に確認します。SITE PORTの完成例と編集デモでは、完成イメージと日常的な編集の流れを確認できます。ドメイン移管、DNS、証明書、HTTPヘッダー等は通常の本文編集と同じ範囲で扱えるとは限らないため、必要な作業を具体的に伝え、対応範囲を確認してください。

関連記事

[HSTSの安全な導入](/articles/hsts-safe-rollout-preload)・[HTTPS警告の見分け方](/articles/https-certificate-warning-check)・[サイト更新が反映されないとき](/articles/website-update-not-visible)