CSP における Report-Only と Enforced の違い

By Mirko Peters · 2026-04-23

Web セキュリティに本気で取り組むなら、Content Security Policy（CSP）の「report-only」モードと「enforced」モードの違いを理解することは、細かい話ではなく本質です。Report-only モードは、何も止めずにポリシーでブロックされる対象を確認できる仕組みで、Web サイトを一種のセキュリティテストの場に変えます。一方の Enforced モードは、ポリシーに反するものをすべてブロックし、サイトをリアルタイムで保護します。

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

Cover: Fix Conditional Access Loopholes in Microsoft 365

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

CSP モードの理解と影響

CSP ヘッダーを設定する前に、CSP の 2 つの主要なモード、report-only と enforced を理解しておく必要があります。これらは単なる設定項目ではなく、最新のブラウザーがお使いの Web アプリケーションのセキュリティ境界をどのように保護する（あるいは監視するだけにとどめる）かを決定します。どちらを選ぶかによって、サイトのリスクレベル、監査能力、展開のスムーズさが直接変わります。特に大規模な Microsoft 環境やマルチクラウド構成では重要です。

CSP のモードは、Web チームに柔軟性をもたらすために設計されました。Report-only モードは導入の第一歩です。ユーザーに影響を与える心配なく問題を監視できます。リスク評価を支援し、ポリシーの抜けを見つけ、古いコードや想定外のサードパーティの動作を特定できます。その間もアプリケーションは完全に稼働し続けます。

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

2 つの CSP モードを用意している背景には、単純な考え方があります。開発者とセキュリティチームが、本番環境に適用する前にルールを磨き上げられるようにすることです。セキュリティの補助輪のようなものですが、最終的には完全な強制適用へと移行するゴールがあります。次のセクションでは、report-only が実環境でどのようなフィードバックを与えるのか、そして enforcement を適用すると何が変わるのかを詳しく見ていきます。

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

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

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

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

Report-only は段階的な展開もサポートします。まずは緩い設定から始め、調整が必要な箇所を確認しながら、少しずつセキュリティを強化していけます。サードパーティスクリプト、CDN のコンテンツ、難読化された JavaScript などの問題を、強制適用によって劇的な障害が起きる前に発見できます。さらに、組織が適切な注意義務を果たしていることを示す必要がある監査の場面でも、積極的に監視していることの証拠になるため、コンプライアンス面でも有効です。

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

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