Content Security Policyにおける「レポート専用」と「適用」の違い

By Mirko Peters · 2026-04-23

Webセキュリティに真剣に取り組むなら、Content Security Policy（CSP）の「レポート専用」と「適用」モードの違いを理解することは、細部どころか要となります。レポート専用モードは、ポリシーによって何がブロックされるかを実際には何も止めずに確認できるため、Webサイトがセキュリティテストの場のような役割を果たします。一方、適用モードは妥協しません。ポリシーに反するものはすべてブロックし、リアルタイムでサイトを守ります。

Automatically translated with AI from the original post. Read the English original

Webセキュリティに真剣に取り組むなら、Content Security Policy（CSP）の「レポート専用」と「適用」モードの違いを理解することは、細部どころか要となります。レポート専用モードでは、ポリシーによって何がブロックされるかを、実際には何も止めずに確認できます。Webサイトがセキュリティテストの場になるイメージです。一方、適用モードは妥協しません。ポリシーに反するものはすべてブロックし、リアルタイムでサイトをロックダウンします。

本記事では、これらのモードが重要な理由、ブラウザーとユーザー体験に与える影響、そして単純な監視から実効性のある保護へ移行する方法を解説します。Microsoft環境のセキュリティ担当者や開発者が、CSPの設定を正しく行えるよう、定義、実践的な手法、安全な展開とスマートなコンプライアンスのためのベストプラクティスを取り上げます。

CSPモードの理解と影響

CSPヘッダーを設定する前に、CSPの2つの主要モード、レポート専用と適用を正しく理解しておく必要があります。これらは単なる設定項目ではなく、最新のブラウザーがWebアプリケーションのセキュリティ境界をどのように保護する（または監視のみを行う）かを左右します。どちらを選ぶかによって、サイトのリスクレベル、監査能力、展開の円滑さが直接変わります。特に大規模なMicrosoft環境やマルチクラウド構成では、その影響は大きくなります。

CSPのモードは、Web開発チームに柔軟性をもたらすために設計されています。レポート専用モードは、いわば穏やかな入り口です。ユーザーに不具合を与える心配をせずに問題を監視できます。リスク評価を支援し、ポリシーの不備を見つけ、レガシーコードや想定外のサードパーティの挙動を特定することもできます。その間、アプリケーションは完全に稼働を続けます。

適用モードは本番の主役です。ブラウザーに対して、ポリシーの指示を実際に実行させます。コンテンツがポリシーに一致しない場合は即座にブロックされ、クロスサイトスクリプティングや悪意のあるサードパーティスクリプトといった攻撃対象領域を、瞬時に減らすことができます。ただし、テストと導入に注意を払わないと、ミスや不完全なポリシーによってアプリケーションが停止するおそれもあります。

CSPの2つのモードを用意している背景にある考え方は単純です。開発者やセキュリティチームが、本番に切り替える前に実環境でルールを磨き上げられるようにすることです。アプリケーションのセキュリティにとっての補助輪のようなものですが、完全適用へ移行するゴールも用意されています。次のセクションでは、レポート専用モードがどのように実環境のフィードバックを提供するのか、そして適用が有効になると何が変わるのかを詳しく見ていきます。

Content-Security-Policy-Report-Onlyによる違反レポートの仕組み

レポート専用モードは、コートに立つ前に客席から試合を見守るようなものです。Content-Security-Policy-Report-Only HTTPヘッダーを使用すると、ブラウザーに「違反を監視するが、何もブロックせず、報告だけ行う」よう指示できます。これにより、指定したエンドポイントに違反レポートが届き、ポリシーが適用されていた場合に何がブロックされるかを全体像として把握できます。

ブラウザーは、リソースがCSPルールに違反するたびに、違反レポートを送信します（多くは JSON ペイロードとして送られます）。たとえば、ページが未承認のソースからスクリプトを読み込もうとした場合、レポート専用モードではそのスクリプトはブロックされません。それでも、問題のURL、違反したディレクティブ、そして場合によっては不審なコードのサンプルといった詳細を含むアラートを受け取れます。

このモードは、リスク評価と安全なテストにとって非常に価値があります。複数のWebアプリにまたがって新しいルールを展開し、どのルールが発動するかを監視して、推測ではなく実際のデータに基づいてポリシーを調整できます。レガシーシステムや、ミッションクリティカルな業務ワークフローを運用している場合でも、急ぎすぎてサイト停止やサポート対応を招くリスクを避けられます。

レポート専用モードは、段階的な展開にも対応します。まずは緩やかに始め、調整が必要な箇所を確認しながら、一歩ずつセキュリティを強化していきます。適用によって大きな障害が起きるまで表面化しないような、サードパーティスクリプト、CDNコンテンツ、難読化されたJavaScriptの問題を発見できます。さらに、積極的に監視していることの証拠を残せるため、組織が相応の注意義務を果たしていることを示す必要がある際に、監査でも役立ちます。

適用モードによるセキュリティ強化

適用モードは、CSP ポリシーが「推奨」から「ルール」に変わるモードです。Content-Security-Policy ヘッダーを使用すると、ブラウザーはディレクティブに一致しないコンテンツを実際にブロックします。警告だけで終わることはなく、確実に動作します。

このモードを使うと、XSS や不正なスクリプトの挿入といった攻撃に対して、Web アプリのセキュリティを大幅に強化できます。ただし注意が必要です。ポリシーが本番運用に耐える状態でない場合、必要なリソースを誤ってブロックし、サイトの機能を損なうおそれがあります。まずはレポート専用モードでテストするのが賢明な進め方です。つまり、適用モードは理論上のポリシーを実際の保護に変えるものであり、強固な Web セキュリティを実現するためのゴールドスタンダードと言えます。

report-uri と report-to エンドポイントによるレポートの実装

レポートを設定すると、CSP ポリシーに実効性と「監視の目」が加わります。CSP では、ブラウザーが違反レポートを送信する先のエンドポイントを、report-uri または report-to で 1 つ以上指定できます。違反が発生すると、ブラウザーはブロックされたリソースや違反したポリシーなどの詳細を JSON または HTTP POST メッセージにまとめ、エンドポイントへ送信します。

report-uri ディレクティブは従来の方式で、指定した URL にブラウザーが直接レポートを送信します。一方、より柔軟で詳細なレポートを求めるなら、新しく堅牢な report-to が適しています。特にブラウザーの Reporting API 対応が広がる中で、その価値は高まっています。report-to は名前付きグループと連携し、さまざまな種類のレポートを扱えるうえ、フィルタリングをより細かく制御できます。

エンドポイントを設定する際は、必ず保護してください。HTTPS の利用、アクセス制御、予期しない急増の監視を行いましょう。急増は攻撃や壊れたポリシーの兆候である可能性があります。また、プライバシーにも配慮が必要です。レポートには URL や問題のあるスクリプトの断片が含まれることがあるため、保存や共有の前に機密情報を除去する準備が欠かせません。GDPR や CCPA などの規制にも注意しましょう。

最大の利点は可視性です。適切にレポートを構成すれば、ポリシーがどこで違反を検出しているかをリアルタイムに把握できます。その情報をもとにポリシーを調整し、問題なく適用モードへ移行できます。この監視は、単一のアプリを管理する場合でも、大規模な Microsoft 365 環境を管理する場合でも不可欠です。

効果的なポリシー設計のための CSP 構文とディレクティブの理解

堅牢な CSP ヘッダーを書くことは、それほど難しいものではありませんが、細部への注意が求められます。特に、複雑なアプリや Microsoft クラウドとの連携を扱う場合は重要です。CSP ポリシーの基本は、ディレクティブの構造化されたリストです。各ディレクティブは、ブラウザーに許可される内容と許可されない内容を指定します。これらのポリシーは HTTP ヘッダーで送信し、通常は Content-Security-Policy または Content-Security-Policy-Report-Only を使用します。セミコロンで区切られたルールの文字列として記述します。

ポリシーの中核となるのは、default-src、script-src、img-src といった主要なディレクティブです。default-src はフォールバックとして機能し、特定の種類のコンテンツに個別のルールがない場合にブラウザーがこの値を確認します。script-src と img-src は、スクリプトと画像をそれぞれ対象とし、信頼できるソース(自社ドメイン、信頼された CDN、場合によっては Microsoft Azure の Blob ストレージなど)を厳密に制御できます。

構文は重要です。各ディレクティブには、許可する値を記述します。URL、'https:' のようなスキーム、'self' のようなキーワードを指定できます。レガシーなコードでインラインスクリプトが必要な場合は 'unsafe-inline' が必要になることがありますが、これは保護を弱めるため注意が必要です。ハッシュや nonce を使用して検証を加えるのが望ましい方法です。

Microsoft 関連の担当者は、クラウドサービスが依存関係をどのように挿入するかに注目してください。複雑なエンタープライズアプリは、アセットを動的に読み込んだり、サービスワーカーを使用したり、サードパーティのプロバイダーと統合したりします。ポリシーはセキュリティのために厳しくしつつ、アプリが動作するだけの柔軟性も必要です。最初に基本を押さえておけば、後のテストははるかにスムーズに進みます。

レポート専用モードから適用モードへの移行のベストプラクティス

CSP で最も賢明な進め方は、まずレポート専用モードで開始してデータを収集し、そのうえで適用を有効にすることです。CSP の導入を一度きりのチェックリストとして扱わないでください。むしろ段階的なプロジェクトとして捉え、監視と調整を繰り返しながらポリシーを徐々に強化していくことで、エンドユーザーや業務上重要なワークフローの機能を損なわずに済みます。

まずは、範囲は広いが現実的なポリシーをレポート専用モードで展開します。違反レポートを収集し、可能であればダッシュボードや分析ツールで集計して、繰り返し発生している違反元を特定します。これにより、ノイズを減らし、誤検知を除外して、実際のリスクに集中できます。定型的または重複したレポートが多い場合(よくあることです)は、ユーザーエージェントやリソースの種類でフィルターをかけるなど、ログ分析を調整してください。

違反件数が減り、大半の問題が解消されたら、新たな不具合を監視しながら、ルールの適用を段階的に開始します。リスクが高くアクセス数の少ないセクションを最初に適用して監視します。問題がなければ、プロジェクトの残りの部分に広げます。変更内容は文書化し、プロセス全体を通じて開発者や関係者からフィードバックを得てください。特に条件付きアクセスの層が加わって複雑になりがちな Microsoft 365 や Azure のアプリでは重要です。関連する戦略や展開計画については、条件付きアクセスの信頼に関する問題についてのこちらのガイドとこちらの ID セキュリティのエピソードもご参照ください。

テストを軽視しないでください。ブラウザーの開発者ツール、CSP ステータステスター、さらには CI/CD による自動スキャンを使って、ポリシーが想定どおりに動作することを確認します。最終的な目標は、実環境で磨き上げられたポリシーによって守られる、ロックダウンされた、準拠性が高く、回復力のあるアプリケーションを実現することです。希望的観測ではなく、実績に基づいた確実な対策が求められます。

レポート専用モードと適用モードにおける CSP の実例

CSP を理解するには、実例を見るのが一番です。レポート専用モードでは、次のようなヘッダーを使用できます: Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://csp-report.example.com。この設定では、すべての違反がログに記録されますが、ユーザーの操作には影響しません。そのため、リスクを負わずに本番環境でテストするのに最適です。

これに対して、適用モードのポリシーは次のとおりです: Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; img-src 'self'; report-uri https://csp-report.example.com。この場合、ブラウザーはルールに合致しないスクリプトや画像をすぐにブロックし、承認されていないコンテンツからユーザーを即座に保護します。

実際には、多くの組織がまずレポート専用モードで、厳格なロックダウン構成を適用した場合に動作しなくなるベンダー、スクリプト、業務機能を洗い出すところから始めます。たとえば、ある行政の Web ポータルでは、古いスクリプトや、マーケティング分析用 CDN が繰り返し違反を発生させていることが判明するかもしれません。その後、検証を重ねて安全なプロバイダーをホワイトリストに登録し、完成したポリシーを段階的に適用して、業務への影響を最小限に抑えます。

レポート専用から適用モードへの移行では、特にサードパーティのスクリプトや動的コンテンツで、思わぬ問題が表面化することがあります。特定のブラウザーや特定の条件下でのみ発生する「幻の」違反に遭遇することも少なくありません。レポート専用フェーズで得られた実データを使ってポリシーを調整することで、適用後のポリシーを安全であるだけでなく、関係者全員にとって安定したものにできます。

レポート専用モードと適用モードの主な違いのまとめ

• 動作: レポート専用モードは、ポリシー違反を報告するだけで、コンテンツはブロックされません。適用モードは、CSP ポリシーに違反するものをすべて実際にブロックします。
• 目的: レポート専用モードでは、ユーザーにリスクを与えることなくポリシーをテストして調整できます。適用モードは実際の保護のためのもので、セキュリティルールを現実に効力のあるものにします。
• ユーザーへの影響: レポート専用モードは目に見えないため、ユーザーが気づくことはありません。事前にルールをテストしていない場合、適用モードでは機能やコンテンツが動作しなくなることがあります。
• ユースケース: レポート専用モードは、段階的な展開、リスク分析、レガシー互換性の確認に最適です。適用モードは、堅牢で準拠性の高いセキュリティを実現するための最終段階です。
• 準拠性とリスク: レポート専用モードは、監視や監査時の文書化に役立ちます。一方、適用モードは、セキュリティ侵害をリアルタイムで直接防止します。