Security

CSPを壊さず導入する手順！Report-Onlyからnonce運用まで

公開日2026.10.18

約8分で読めます

※本ページのリンクにはプロモーションが含まれています。

Webページのスクリプト許可と違反報告を表すチャコール背景のフラットな概念イラスト

CSPを導入したら画面が動かなくなり、必要そうなドメインやunsafe-inlineを追加し続けた。ヘッダーは付いていても、何を防げるか説明できない状態では、運用するほど許可が増えてしまいます。最初に決めるべきなのは、使いたい設定文字列ではなく、ページで実行・読み込みを許すものです。

本稿は2026年10月18日にMDNとOWASPの資料を確認した導入ガイドです。特定の事件の速報ではありません。画面や構成の例は仮想で、導入の順序、確認票、例外管理は本サイトによる提案です。

CSPが補う範囲とアプリ側で直す範囲

Content Security Policyは、ブラウザーへリソースの読み込みや実行などの許可条件を伝える仕組みです。XSSによる影響を小さくする層として使えますが、入力を安全に表示する実装や、認証・認可の代わりにはなりません。

たとえば不適切なHTMLの生成があるなら、その原因は修正します。CSPで今は実行が止まっているから危険な出力を残してよい、という設計にしません。また、許可した正規スクリプトが不正な処理を行う場合まで、自動的にすべて見抜く仕組みではありません。

この区別を導入票へ書きます。エスケープやサニタイズを担当する実装、CSPを生成する場所、違反を確認する担当を分けると、ヘッダーだけで安全性を保証したという誤解を減らせます。既存のXSS解説とは、今回はブラウザーのポリシーを配信・維持する工程に焦点を置いています。

基本となる資料：MDN：Content Security Policyガイド。

最初に読み込みと実行の依存先を調べる

本サイトの提案は、ページ種類ごとにスクリプト、スタイル、画像、フォント、埋め込み、通信先を調べる方法です。トップページだけでなく、フォーム、会員画面、決済、記事編集など、異なる機能を代表させます。ログイン状態や同意設定で読み込みが変わる場合も含めます。

外部タグがさらに別のスクリプトを読み込むこともあります。追加する許可が何の業務に必要で、誰が管理するかを残します。利用していない解析タグや古い埋め込みを整理できれば、CSPを広げる前に依存そのものを減らせます。

一覧に見つからない読み込みを、後からすべて自動で許可する運用にはしません。違反の報告が、正規機能、ブラウザー拡張、試験用のアクセス、不審な入力のどれによるものかを切り分けます。報告件数だけを少なくすることを目標にしないでください。

Report-Onlyで観測してから強制を選ぶ

Content-Security-Policy-Report-Onlyは、ポリシー違反を報告するためのもので、そのポリシーによる遮断を実施する強制ヘッダーとは区別します。導入時に影響を調べるために使えても、これだけを付けた期間を遮断済みと報告しないことが重要です。

本サイトでは、まず重要な操作を試し、報告とブラウザーのコンソールを照合する工程を勧めます。通常利用で発生しない条件は、少量の試験データで代表させます。外部サービスの遷移や埋め込みは、サイト運営者の画面だけでは確認し切れない場合があります。

報告先を設ける場合は、URLなどの情報が集まる可能性を考え、保存期間と閲覧者を決めます。収集先自体の負荷や不正な送信も管理対象です。報告を集め続けるだけで終わらないよう、強制へ切り替える条件、担当、例外の期限を設定します。

nonceはレスポンスごとに生成し信頼した要素へ付ける

MDNは、nonceやハッシュを使うポリシーを説明しています。nonce方式では、応答ごとに予測できない値を生成し、ポリシーと許可するscriptなどの要素へ一致する値を入れます。固定の文字列を全ページで使い回す方法ではありません。

重要なのは、HTML内のすべてのscriptへ後処理でnonceを付けないことです。MDNは、攻撃者が挿入した要素へまでnonceを与える危険を指摘しています。信頼するテンプレートが出力する要素と、外部入力由来の内容を区別します。

フレームワークやCMSを使う場合は、標準的なnonce連携や配信方式を確認します。表示結果だけを文字列置換する独自処理より、信頼する生成箇所で扱う方法を優先します。値が漏れないことだけでなく、毎回の生成と必要な要素への伝達が正しいことを試験してください。

キャッシュとnonceを別々に更新しない

nonceがヘッダー側とHTML側で一致しなければ、正規スクリプトが実行できなくなります。本サイトが提案する確認は、キャッシュに命中した応答、再生成した応答、ログイン状態の違いを分けて見ることです。CDNがHTMLだけ保存し、ヘッダーだけ別の値へ変える構成になっていないかを調べます。

静的なページなどでは、ハッシュを使う方式が候補になります。ハッシュは許可する内容に対応するため、その内容を変更したらポリシーの更新も必要です。ビルド成果物とヘッダーの生成を同じリリースに結び付ける方法を検討します。

どの方式でも、古いHTMLと新しいポリシーが混在する期間を考えます。キャッシュの失効、リリース順序、戻す対象を事前に決めます。「障害が出たので全許可に戻す」を唯一の復旧策にせず、直前の検証済みポリシーへ戻せるようにします。

広い許可を足す前に信頼の範囲を考える

unsafe-inlineやunsafe-evalのような指定は、必要性と影響を理解して扱います。MDNはunsafe-inlineがCSPの目的の多くを弱めると説明しています。違反の理由が分からないまま追加して、エラーが消えたことを安全の証拠にしないでください。

strict-dynamicを使う場合も、nonceやハッシュで信頼されたスクリプトから、後続のスクリプト読み込みへ信頼が伝わることを理解します。外部タグを一つ許可する行為が、その文字列だけの許可より広い意味を持つ場合があります。導入する理由と管理者を確認します。

iframeなどでの表示を制御するframe-ancestorsのように、一般の読み込み制御とは役割が違う指定もあります。すべてがdefault-srcへ同じように従うと想像せず、採用するディレクティブの仕様を確認します。単一のコピペ設定を全画面へ適用するより、必要な機能から構成します。

管理画面と公開画面を同じポリシーへ押し込まない

会員画面、公開記事、編集画面では依存する機能が違います。本サイトでは、ページの責任範囲に応じてポリシーの適用単位を選び、なぜ違うのかを記録する方法を勧めます。管理画面で必要な広い許可を、そのまま匿名向けページへ引き継がないようにします。

例外には、対象ページ、必要な外部機能、追加する許可、削除予定を付けます。広告、問い合わせ、動画、決済などの担当と相談し、使わない機能を止める選択肢も含めます。CSPだけを担当する人が、業務の用途を知らずに永久の例外を承認しない体制が必要です。

運用後も新しいタグやプラグインを追加する変更に、CSPの確認を含めます。ヘッダーの更新が別部署なら、実装の公開とポリシー変更の順序を共有します。機能の追加を、後から許可を広げるだけの作業にしないでください。

決済や埋め込みを含むページを安全に移行する例

仮想のサイトで、記事ページは静的に配信し、購入画面だけが外部決済と連携するとします。全ページで同じポリシーを使って購入画面の例外を増やすと、記事ページにも不要な許可が広がります。本サイトは、ページの役割ごとに必要な通信を整理し、例外の影響範囲を小さくすることを勧めます。

まず検証環境で通常の閲覧、検索、フォーム送信、決済完了までの操作を記録します。その後、Report-Onlyで想定していない接続先を調べます。ブラウザー拡張による報告や一時的な接続失敗まで機械的に許可へ追加しないようにします。報告の発生源と、業務として必要な通信かを分けて判断します。

運用上の合意が必要なのは、タグ管理やマーケティング担当が後からスクリプトを増やす場合です。CSPを固定した後でも、許可する接続先とコードの供給元を変更できる人を把握します。許可済みの外部コードが何を実行するかまでCSPが無条件に保証するわけではないため、提供元の選定と変更管理は残ります。

切り戻しでは、検証した既知のポリシーへ戻せるようにします。障害が出るたびにunsafe-inlineなどを追加し続けると、導入時の目的が失われます。どの機能がどの制限で止まったかを確認し、ポリシー、テンプレート、キャッシュのどこを直すべきかを切り分けます。

確認対象	見るべき結果	避けたい対応
通常の記事表示	必要なコードだけが実行される	全接続先を一括で許可する
決済画面	正規の手順が最後まで通る	理由不明のまま全ページを緩める
nonce付き応答	本文とヘッダーの値が一致する	異なる応答のキャッシュを混在させる
違反報告	必要性と原因を分類できる	報告先の文字列をそのまま許可へ足す