Reportingとエラー収集の仕組み（report-to/CSPレポート）

本番環境で起きる Content Security Policy 違反や、廃止予定 API の利用、レンダラーのクラッシュは、ユーザーの画面の中で起きるため開発者には見えません。Reporting API は、こうしたブラウザ自身が検知したイベントを構造化レポートとしてサーバーへ自動送信する標準機構です。ページの JavaScript を介さずブラウザが直接配送する点が肝で、JS が止まるような状況でも報告が届きます。ここでは配送モデルと、window.onerror 系との役割分担を原理から見ていきます。

レポートはどこから生まれ、どう配送されるか

レポートを生み出すのはアプリケーションコードではなくブラウザです。CSP のソースリスト照合に失敗した、非推奨 API を呼んだ、Permissions-Policy で禁止した機能を使おうとした、レンダラープロセスが落ちた——こうした瞬間にブラウザがレポートオブジェクトを内部キューへ積みます。各レポートは type（csp-violation／deprecation／intervention／crash など）、url、そして型ごとの body を持つ JSON です。

配送先はレスポンスヘッダで宣言します。現行仕様は Reporting-Endpoints で、名前=URL の形でエンドポイントに名前を付けます。

Reporting-Endpoints: main="https://reports.example.com/main",
                      csp="https://reports.example.com/csp"

ブラウザはレポートを即時には送りません。同じエンドポイント宛のレポートを一定時間まとめてバッチ化し、Content-Type: application/reports+json の配列ボディとして非同期 POST します。送信はベストエフォートで、ページのライフサイクルとは独立して動くため、ユーザーが離脱した後でも届くことがあります。これが「JS が介在しない」配送の実体です。

CSP・COOP レポートの紐付け

セキュリティポリシー側は、エンドポイントの名前を指すだけでレポートを配送できます。CSP なら report-to ディレクティブにエンドポイント名を書きます。

Content-Security-Policy: script-src 'self'; report-to csp
Reporting-Endpoints: csp="https://reports.example.com/csp"

違反が起きると、ブラウザは csp-violation 型のレポートを生成し、csp という名前のエンドポイント宛キューへ積みます。body には blockedURL、violatedDirective、effectiveDirective、originalPolicy、disposition（enforce か report）などが入ります。Content-Security-Policy-Report-Only を使えばブロックせずレポートだけ集められ、本番強制前の検証に使えます。この段階的導入の考え方は Content Security Policyの内部動作と回避耐性 で詳述しています。

COOP（Cross-Origin-Opener-Policy）も同じ仕組みに乗ります。report-to パラメータを付けると、ポップアップやオープナーとの分離に関する違反が coop 型などで届きます。COOP は同一オリジンポリシーとサイト分離の信頼境界が定めるプロセス分離・クロスオリジン隔離を運用面で支えるもので、レポートは「分離が想定通りか」を本番で確認する手段になります。

Permissions-Policy 由来の Permissions-Policy-Report-Only も同経路で配送されます。どの機能がどのフレームで拒否されたかを把握でき、ポリシー設計の検証に有効です。これは Permissions Policyによる機能ゲート と組み合わせて使います。

ReportingObserver — ページ内から観測する

サーバー配送とは別に、ページの JS から同じレポートストリームを読む手段が ReportingObserver です。これはネットワーク送信ではなく、ブラウザが生成したレポートをドキュメント内で受け取るオブザーバです。

const observer = new ReportingObserver((reports, observer) => {
  for (const report of reports) {
    // report.type === "deprecation" など
    console.log(report.type, report.body);
  }
}, { buffered: true });
observer.observe();

buffered: true を指定すると、オブザーバ生成前に溜まっていたレポートも初回コールバックで受け取れます。CSP 違反のように設計上 JS へ露出しない型もありますが、deprecation や intervention はここで拾えるため、自前のテレメトリへ流す用途に向きます。サーバー配送が「ブラウザ→自分のサーバー」なのに対し、ReportingObserver は「ブラウザ→同一ドキュメントの JS」で、後者はレポートを加工・サンプリングしてから送りたいときに使います。

window.onerror／unhandledrejection との関係

ここを混同すると監視に穴が空きます。window.onerror と unhandledrejection は JavaScript 実行時に発生した例外を捕まえるフックで、Reporting API とは発生源も配送経路も異なります。

• window.onerror（または addEventListener('error')）は、スクリプト実行中にスローされ捕捉されなかった例外を同期的に同一ドキュメント内で受け取ります。クロスオリジンのスクリプトでは、CORS の crossorigin 属性が無いとメッセージが Script error. に丸められ、スタックも失われます。
• unhandledrejection は、.catch されなかった Promise の reject を非同期に拾います。await の失敗を握りつぶしたコードはここに現れます。

これらは「アプリのコードが投げたエラー」を拾うもので、配送は自分で fetch するなど JS の責任です。一方 Reporting API が扱うのは「ブラウザが検知したポリシー違反やプロセスの状態」で、CSP 違反やレンダラークラッシュは JS の例外ではないため window.onerror には一切現れません。逆に、自前の throw new Error() は Reporting API のレポートにはなりません。

信頼境界とエンドポイント設計

レポートエンドポイントには Origin ヘッダ付きの POST が届きますが、ブラウザによっては配送前にプリフライト相当の確認を行います。受信側は送信元 url を検証し、攻撃者が偽レポートを大量送信する DoS／ノイズ混入に備えてレート制限を入れるべきです。レポートは Service Worker の fetch ハンドラを経由しない点にも注意が必要で、Service Workerのライフサイクルとスコープ制御で扱う傍受はレポート配送には効きません。これは、SW 自体が壊れていてもレポートが届くようにするための設計です。