読者からの不具合報告を待たずにContent Security Policyを導入する方法

Content Security Policyの導入は、観察と代表的なページの選定から始めます。コピーしたポリシーでトップページは安全に見えても、記事のメディア、支払い、編集者のプレビューが壊れる場合があります。目的は不要な実行を制限しつつ、媒体が意図して提供する機能を保つことです。

CSPの仕様では、強制するポリシーと、候補を強制せず監視するContent-Security-Policy-Report-Onlyを区別しています。report-onlyは候補の影響を学ぶ方法です。その候補を強制した場合の保護を提供せず、別に有効になっているポリシーを無効にすることもありません。

実際に運用するサイトを把握する

ルールを書く前に代表的なページ種別と利用経路を列挙します。標準記事、メディアのあるページ、検索、翻訳版、実在する商業機能を含めます。想像上のサービスは加えません。アカウント、追跡、決済スクリプトがない静的媒体と、会員制事業では依存関係が異なります。

経路ごとに必要なスクリプト、スタイル、画像、フォント、フレーム、接続を特定します。外部依存の担当者と目的を記録します。ブラウザーに見えたホスト名は調査の手掛かりであり、その配信物すべてを信頼する許可ではありません。例外追加の前に、その機能が本当に必要か確認します。

実際の応答ヘッダーと配信経路を調べます。ポリシーはオリジン、ホスティング設定、配信レイヤーで付与される場合があります。複数箇所がヘッダーを出すなら、編集前に正となる設定を決めます。そうしなければ、開発者がローカル設定を変えても読者は別のポリシーを受け取り続けます。

候補をreport-onlyヘッダーとして配信する

仕様ではmeta要素内のreport-onlyをサポートしていません。サイトの対応する公開手順でHTTP応答ヘッダーを設定します。現在強制しているポリシーも把握してください。追加の候補を観察していても、既存の制限がすべて取り除かれた証明にはなりません。

対応する報告方式を選び、受信エンドポイントが想定するレポートを受け付けるか確認します。MDNのヘッダー解説は配信と報告設定を説明しています。ディレクティブを書くだけで、受信、保存、確認するサービスが生まれるわけではありません。

最初の実験は理解できる範囲に絞ります。媒体に適した管理環境や限定公開を使い、以前の設定を残します。ブラウザーコンソールと収集経路の両方を試します。レポートが来なければ、違反がないと判断する前に、収集自体が機能するか調べます。

受信レポートは信頼できない入力として扱います。不要な保存を抑え、収集先へのアクセスを保護し、広く共有する障害連絡先へ機密性の高いページURLを出さないようにします。レポートには訪問者のページ状況に関する情報が含まれる場合があります。外部サービスを単なる中立な通路とせず、採用前に収集内容を確認します。

レポートを許可の積み増しではなく判断につなげる

ページ種別、ディレクティブ、リソースごとに結果を整理します。想定する経路で代表的な失敗を再現します。拡張機能や特殊なクライアント状態がノイズを作る場合もあり、報告だけで新しい配信元を自動許可してはいけません。一方、想定外の項目をすべてノイズと片付ければ、本当の連携不具合を隠します。

正当な依存関係ごとに、維持、置換、削除を決めます。広い例外が増えると古いスクリプトをすべて残したまま、ポリシーの意味を弱めます。OWASPのCSPガイドにはnonceやハッシュを使う強い方式もあります。必要なのは正しい生成と配信であり、固定のサンプル値の使い回しではありません。

nonceを使うなら、プレビュー、言語版、キャッシュに特に注意します。ヘッダーと許可したマークアップが同じ応答方式に属する必要があります。配信レイヤーが読者ごとの内容を変えるならキャッシュルールの確認を使います。キャッシュを使わない開発者の成功例が、公開キャッシュ版を代表するとは限りません。

管理した変更で強制し、観察を続ける

受け入れ基準は報告の静かさだけでなく機能で決めます。記事を開けるか、予定したメディアを再生できるか、実際の有料経路を完了できるか。編集者はプレビューできるか。必要な言語、画面、同意状態を試したか。収集が不完全な場合もあり、違反記録がないことは全経路を通った証明ではありません。

強制前にポリシーの版、試験事例、既知の限界、正確な戻し方を記録します。ステージングとロールバックの手順を使って公開します。通常のリリース経路で強制ポリシーを変え、公開後のヘッダーと同じ操作を確認します。初期観察中は担当者が対応できるようにします。

変更後はエラー報告と動作の証拠を合わせます。正当な重要機能が失敗したら、動作が分かっている設定へ戻すか、理解した範囲の狭い修正を行います。警告を消すために全配信元を広く許可しないでください。修復を、必要とした依存先と挙動に結び付けて説明できることが重要です。

今後のリリースでも依存一覧とポリシー確認を維持します。提供元を外したら不要な権限も外し、機能追加では適合性を確認します。CSPはヘッダーを一度付けて得る認定ではなく、アプリケーションの安全性やアクセス制御と並ぶ、保守する配信の一部として機能します。