Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

Reporting API を使用してウェブアプリケーションをモニタリングする

Reporting API を使用して、セキュリティ違反、非推奨の API 呼び出しなどをモニタリングします。

Maud Nalpas

一部のエラーは本番環境でのみ発生します。実際のユーザー、実際のネットワーク、実際のデバイスによってゲームが変わるため、ローカルや開発中に確認することはできません。Reporting API は、セキュリティ違反や、サイト全体で非推奨またはまもなく非推奨になる API 呼び出しなど、これらのエラーの一部をキャッチし、指定したエンドポイントに送信します。

HTTP ヘッダーを使用してモニタリングする内容を宣言でき、ブラウザによって動作します。

Reporting API を設定しておくと、ユーザーがこのようなエラーに遭遇したときに、そのことを把握して修正できます。

この投稿では、この API でできることと、その使用方法について説明します。詳しく見ていきましょう。

概要

レポートの生成からデベロッパーによるレポートへのアクセスまでの手順をまとめた図 — レポートの生成と送信の仕組み。

サイト site.example に Content-Security-Policy と Document-Policy があるとします。これらの機能が何をするものかわからない場合は、この例は引き続き理解できます。

これらのポリシーが違反されたタイミングを把握するため、また、コードベースで使用されている可能性のある非推奨の API や、まもなく非推奨になる API を監視するために、サイトをモニタリングすることにします。

これを行うには、Reporting-Endpoints ヘッダーを構成し、必要に応じてポリシーの report-to ディレクティブを使用してこれらのエンドポイント名をマッピングします。

Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"

# Content-Security-Policy violations and Document-Policy violations
# will be sent to main-endpoint
Content-Security-Policy: script-src 'self'; object-src 'none'; report-to main-endpoint;
Document-Policy: document-write=?0; report-to=main-endpoint;
# Deprecation reports don't need an explicit endpoint because
# these reports are always sent to the `default` endpoint

予期しない事態が発生し、一部のユーザーに対してこれらのポリシーが違反される。

違反の例

index.html

<script src="script.js"></script>
<!-- CSP VIOLATION: Try to load a script that's forbidden as per the Content-Security-Policy -->
<script src="https://example.com/script.js"></script>

script.js、index.html が読み込み

// DOCUMENT-POLICY VIOLATION: Attempt to use document.write despite the document policy
try {
  document.write('<h1>hi</h1>');
} catch (e) {
  console.log(e);
}
// DEPRECATION: Call a deprecated API
const webkitStorageInfo = window.webkitStorageInfo;

ブラウザは、これらの問題をキャプチャする CSP 違反レポート、Document-Policy 違反レポート、非推奨レポートを生成します。

その後、ブラウザは、この違反タイプ用に構成されたエンドポイントにレポートを送信します。このとき、最大 1 分の遅延が発生します。レポートは、ブラウザ自体（サーバーやサイトではなく）によって帯域外で送信されます。

エンドポイントはこれらのレポートを受信します。

これらのエンドポイントのレポートにアクセスして、問題の原因をモニタリングできるようになりました。これで、ユーザーに影響を与えている問題のトラブルシューティングを開始する準備が整いました。

サンプルレポート

{
  "age": 2,
  "body": {
    "blockedURL": "https://site2.example/script.js",
    "disposition": "enforce",
    "documentURL": "https://site.example",
    "effectiveDirective": "script-src-elem",
    "originalPolicy": "script-src 'self'; object-src 'none'; report-to main-endpoint;",
    "referrer": "https://site.example",
    "sample": "",
    "statusCode": 200
  },
  "type": "csp-violation",
  "url": "https://site.example",
  "user_agent": "Mozilla/5.0... Chrome/92.0.4504.0"
}

ユースケースとレポートタイプ

Reporting API を構成すると、サイト全体で発生するさまざまな種類の警告や問題をモニタリングできます。

レポートの種類	レポートが生成される状況の例
CSP 違反（レベル 3 のみ）	ページの 1 つに `Content-Security-Policy`（CSP）を設定しましたが、そのページで CSP で許可されていないスクリプトを読み込もうとしています。
COOP 違反	ページに `Cross-Origin-Opener-Policy` を設定しましたが、クロスオリジンウィンドウがドキュメントを直接操作しようとしています。
COEP 違反	ページに `Cross-Origin-Embedder-Policy` を設定しましたが、ドキュメントにはクロスオリジンドキュメントによる読み込みをオプトインしていないクロスオリジン iframe が含まれています。
ドキュメントポリシー違反	ページに `document.write` の使用を禁止するドキュメントポリシーがあるが、スクリプトが `document.write` を呼び出そうとしている。
権限に関するポリシー違反	このページには、マイクの使用を禁止する権限ポリシーと、音声入力をリクエストするスクリプトがあります。
非推奨の警告	ページで、非推奨または非推奨になる API が使用されています。その API は、直接呼び出されるか、トップレベルのサードパーティスクリプトを使用して呼び出されます。
介入	ページが、セキュリティ、パフォーマンス、ユーザーエクスペリエンス上の理由からブラウザが許可しない処理を行おうとしています。Chrome の例: ページで `document.write` が低速ネットワークで使用されている、またはユーザーがまだ操作していないクロスオリジンフレームで `navigator.vibrate` が呼び出されている。
衝突事故	サイトが開いているときにブラウザがクラッシュする。

レポート

ブラウザは、構成したエンドポイントにレポートを送信します。次のようなリクエストを送信します。

POST
Content-Type: application/reports+json

これらのリクエストのペイロードはレポートのリストです。

レポートのリストの例

[
  {
    "age": 420,
    "body": {
      "columnNumber": 12,
      "disposition": "enforce",
      "lineNumber": 11,
      "message": "Document policy violation: document-write is not allowed in this document.",
      "policyId": "document-write",
      "sourceFile": "https://site.example/script.js"
    },
    "type": "document-policy-violation",
    "url": "https://site.example/",
    "user_agent": "Mozilla/5.0... Chrome/92.0.4504.0"
  },
  {
    "age": 510,
    "body": {
      "blockedURL": "https://site.example/img.jpg",
      "destination": "image",
      "disposition": "enforce",
      "type": "corp"
    },
    "type": "coep",
    "url": "https://dummy.example/",
    "user_agent": "Mozilla/5.0... Chrome/92.0.4504.0"
  }
]

各レポートで確認できるデータは次のとおりです。

フィールド	説明
`age`	レポートのタイムスタンプと現在の時刻の間のミリ秒数。
`body`	実際のレポートデータ。JSON 文字列にシリアル化されます。レポートの `body` に含まれるフィールドは、レポートの `type` によって決まります。⚠️ レポートの種類によって本文が異なります。
`type`	レポートタイプ（`csp-violation`、`coep` など）。
`url`	レポートが生成されたドキュメントまたはワーカーのアドレス。ユーザー名、パスワード、フラグメントなどのセンシティブデータは、この URL から削除されます。
`user_agent`	レポートの生成元となったリクエストの `User-Agent` ヘッダー。

認証情報付きレポート

レポートを生成するページと同一オリジンのレポートエンドポイントは、レポートを含むリクエストで認証情報（Cookie）を受け取ります。

認証情報は、レポートに関する有用な追加のコンテキストを提供します。たとえば、特定のユーザーのアカウントでエラーが継続的に発生しているかどうか、他のページで行われた特定の一連の操作がこのページでレポートをトリガーしているかどうかなどです。

ブラウザがレポートを送信するタイミングと方法

レポートはサイトから帯域外で配信される: ブラウザは、構成されたエンドポイントに送信されるタイミングを制御します。また、ブラウザがレポートを送信するタイミングを制御する方法もありません。ブラウザは、レポートをキャプチャしてキューに入れ、適切なタイミングで自動的に送信します。

つまり、Reporting API を使用する際にパフォーマンス上の懸念はほとんどありません。

レポートは遅延されたうえで送信されます（最大 1 分）。これにより、レポートを一括送信できる可能性が高まります。これにより、帯域幅を節約してユーザーのネットワーク接続を尊重できます。これは、モバイルでは特に重要です。また、優先度の高い処理でビジー状態になっている場合や、ユーザーが低速または混雑したネットワークを使用している場合も、ブラウザは配信を遅らせることがあります。

サードパーティとファーストパーティの問題

ページで発生した違反または非推奨により生成されたレポートは、構成したエンドポイントに送信されます。これには、ページで実行されているサードパーティスクリプトによって発生した違反も含まれます。

ページに埋め込まれたクロスオリジン iframe で発生した違反や非推奨は、エンドポイントに報告されません（少なくともデフォルトでは報告されません）。iframe は独自のレポートを設定し、サイト（ファーストパーティ）のレポートサービスにレポートすることもできますが、これはフレーム付きサイト次第です。また、ほとんどのレポートは、ページのポリシーに違反した場合にのみ生成されます。ページのポリシーと iframe のポリシーは異なります。

非推奨の例

ページに Reporting-Endpoints ヘッダーが設定されている場合、ページで実行されているサードパーティスクリプトによって呼び出された非推奨の API 呼び出しがエンドポイントに報告されます。ページに埋め込まれた iframe によって呼び出された非推奨の API は、エンドポイントに報告されません。非推奨レポートは、iframe サーバーが Reporting-Endpoints を設定している場合にのみ生成され、このレポートは iframe のサーバーが設定したエンドポイントに送信されます。 — Reporting-Endpoints ヘッダーがページに設定されている場合、ページで実行されているサードパーティスクリプトによって呼び出された非推奨の API 呼び出しがエンドポイントに報告されます。ページに埋め込まれた iframe によって呼び出された非推奨の API は、エンドポイントに報告されません。サポート終了レポートは、iframe サーバーが Reporting-Endpoints を設定している場合にのみ生成され、iframe のサーバーが設定したエンドポイントに送信されます。

ブラウザサポート

次の表に、Reporting API v1（Reporting-Endpoints ヘッダーを使用）のブラウザサポートの概要を示します。Reporting API v0（Report-To ヘッダー）のブラウザサポートは、1 つのレポートタイプを除いて同じです。新しい Reporting API では、ネットワークエラーロギングはサポートされていません。詳しくは、移行ガイドをご覧ください。

レポートの種類	Chrome	Chrome iOS	Safari	Firefox	エッジ
CSP 違反（レベル 3 のみ）*	✔ はい	✔ はい	✔ はい	✘ いいえ	✔ はい
ネットワークエラーロギング	✘ いいえ	✘ いいえ	✘ いいえ	✘ いいえ	✘ いいえ
COOP/COEP の違反	✔ はい	✘ いいえ	✔ はい	✘ いいえ	✔ はい
その他のすべてのタイプ: ドキュメントポリシー違反、サポート終了、介入、クラッシュ	✔ はい	✘ いいえ	✘ いいえ	✘ いいえ	✔ はい

この表は、新しい Reporting-Endpoints ヘッダーを使用した report-to のサポートのみをまとめたものです。Reporting-Endpoints への移行を検討している場合は、CSP レポートの移行に関するヒントをご覧ください。

Reporting API の使用

レポートの送信先を決定する

次のいずれかの方法でご対応ください。

既存のレポートコレクタサービスにレポートを送信します。
自分で構築して運用するレポートコレクタにレポートを送信する。

オプション 1: 既存のレポートコレクタサービスを使用する

レポート収集サービスの例を次に示します。

他のソリューションをご存じの場合は、問題を開いてお知らせください。この投稿を更新します。

レポートコレクタを選択する際は、料金に加えて次の点を考慮してください。 🧐

このコレクタはすべてのレポートタイプをサポートしていますか？たとえば、すべてのレポートエンドポイントソリューションが COOP/COEP レポートをサポートしているわけではありません。
アプリケーションの URL を第三者のレポート収集ツールと共有することに抵抗はありますか？ブラウザがこれらの URL から機密情報を削除しても、この方法で機密情報が漏洩する可能性があります。アプリケーションにとってリスクが高すぎると思われる場合は、独自のレポートエンドポイントを運用してください。

オプション 2: 独自のレポートコレクタを構築して運用する

レポートを受信する独自のサーバーを構築するのは簡単ではありません。まず、軽量のボイラープレートをフォークします。Express で構築されており、レポートを受信して表示できます。

独自のレポートコレクタを構築する場合:

Content-Type が application/reports+json の POST リクエストを確認して、ブラウザからエンドポイントに送信されたレポートリクエストを認識します。
エンドポイントがサイトとは異なるオリジンにある場合は、CORS プリフライトリクエストをサポートしていることを確認してください。

オプション 3: オプション 1 と 2 を組み合わせる

特定の種類のレポートは特定のプロバイダに処理させ、他のレポートは社内ソリューションで処理することもできます。

この場合は、次のように複数のエンドポイントを設定します。

Reporting-Endpoints: endpoint-1="https://reports-collector.example", endpoint-2="https://my-custom-endpoint.example"

`Reporting-Endpoints` ヘッダーを構成する

Reporting-Endpoints レスポンスヘッダーを設定します。値は、1 つまたは一連のカンマ区切りの Key-Value ペアである必要があります。

Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"

以前の Reporting API から新しい Reporting API に移行する場合は、Reporting-Endpoints と Report-To の両方を設定することをおすすめします。詳しくは、移行ガイドをご覧ください。特に、report-uri ディレクティブのみを使用して Content-Security-Policy 違反のレポートを使用している場合は、CSP レポートの移行手順を確認してください。

Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"
Report-To: ...

キー（エンドポイント名）

各キーには、main-endpoint や endpoint-1 など、任意の名前を指定できます。レポートタイプごとに異なる名前付きエンドポイントを設定できます（例: my-coop-endpoint、my-csp-endpoint）。これにより、レポートの種類に応じて異なるエンドポイントにレポートをルーティングできます。

介入、サポート終了、クラッシュのレポート、またはこれらの組み合わせを受け取る場合は、default という名前のエンドポイントを設定します。

Reporting-Endpoints ヘッダーで default エンドポイントが定義されていない場合、このタイプのレポートは送信されません（ただし、生成はされます）。

キーポイント: その名前にもかかわらず、default はフォールバックエンドポイントではありません。たとえば、 Document-Policy に report-to my-endpoint を設定し、 Reporting-Endpoints で my-endpoint の定義を省略すると、Document-Policy の違反レポートは生成されますが、ブラウザが送信先を認識していないため、送信されません。

値（URL）

各値は、レポートの送信先となる任意の URL です。ここで設定する URL は、ステップ 1 で決定した内容によって異なります。

エンドポイント URL:

スラッシュ（/）で始まる必要があります。相対パスはサポートされていません。
クロスオリジンにできますが、その場合、レポートとともに認証情報が送信されません。

例

Reporting-Endpoints: my-coop-endpoint="https://reports.example/coop", my-csp-endpoint="https://reports.example/csp", default="https://reports.example/default"

その後、各名前付きエンドポイントを適切なポリシーで使用することも、すべてのポリシーで 1 つのエンドポイントを使用することもできます。

ヘッダーの設定場所

この投稿で説明する新しい Reporting API では、レポートはドキュメントの範囲に限定されます。つまり、1 つのオリジンに対して、site.example/page1 や site.example/page2 などの異なるドキュメントが異なるエンドポイントにレポートを送信できます。

サイトのいずれかのページで発生した違反または非推奨に関するレポートを受け取るには、すべてのレスポンスでヘッダーをミドルウェアとして設定します。

Express の例を次に示します。

const REPORTING_ENDPOINT_BASE = 'https://report.example';
const REPORTING_ENDPOINT_MAIN = `${REPORTING_ENDPOINT_BASE}/main`;
const REPORTING_ENDPOINT_DEFAULT = `${REPORTING_ENDPOINT_BASE}/default`;

app.use(function (request, response, next) {
  // Set up the Reporting API
  response.set(
    'Reporting-Endpoints',
    `main-endpoint="${REPORTING_ENDPOINT_MAIN}", default="${REPORTING_ENDPOINT_DEFAULT}"`,
  );
  next();
});

注: これは、1 つのページに「アンビエント」エンドポイントを設定し、同じオリジンの任意のページのレポートを自動的に取得できる従来の Reporting API（Report-To ヘッダー）とは異なります。以前の Reporting API から新しい Reporting API に移行する場合は、移行ガイドをご覧ください。

ポリシーを編集する

Reporting-Endpoints ヘッダーが構成されたので、違反レポートを受け取るポリシーヘッダーごとに report-to ディレクティブを追加します。report-to の値は、構成した名前付きエンドポイントのいずれかにする必要があります。

複数のポリシーに複数のエンドポイントを使用することも、ポリシー間で異なるエンドポイントを使用することもできます。

各ポリシーについて、report-to の値は、構成した名前付きエンドポイントのいずれかにする必要があります。

report-to は、非推奨、介入、クラッシュのレポートには必要ありません。これらのレポートはどのポリシーにもバインドされていません。default エンドポイントが設定されている限り生成され、この default エンドポイントに送信されます。

例

# Content-Security-Policy violations and Document-Policy violations
# will be sent to main-endpoint
Content-Security-Policy: script-src 'self'; object-src 'none'; report-to main-endpoint;
Document-Policy: document-write=?0;report-to=main-endpoint;
# Deprecation reports don't need an explicit endpoint because
# these reports are always sent to the default endpoint

警告: すべてのポリシーで同じヘッダー構造が使用されているわけではないため、report-to 構文を正しく取得するのは難しい場合があります。ポリシーに応じて、正しい構文は report-to=main-endpoint または report-to main-endpoint になります。

レポートの設定をデバッグする

レポートを意図的に生成する

Reporting API を設定する際は、レポートが想定どおりに生成、送信されるかどうかを確認するために、意図的にポリシーに違反する必要がある場合があります。

時間の節約

レポートは遅延して送信されることがあります。約 1 分の遅延は、デバッグ時には長い時間です。😴 幸いなことに、Chrome でデバッグを行う場合は、--short-reporting-delay フラグを使用して、レポートが生成されるとすぐにレポートを受け取ることができます。

ターミナルで次のコマンドを実行して、このフラグをオンにします。

YOUR_PATH/TO/EXECUTABLE/Chrome --short-reporting-delay

DevTools を使用する

Chrome では、DevTools を使用して、送信済みまたは送信予定のレポートを確認できます。

2021 年 10 月の時点では、この機能は試験運用版です。使用する手順は次のとおりです。

Chrome バージョン 96 以降を使用する（ブラウザに chrome://version と入力して確認）
Chrome のアドレスバーに「chrome://flags/#enable-experimental-web-platform-features」と入力するか、貼り付けます。
[有効] をクリックします。
ブラウザを再起動する。
Chrome DevTools を開きます。
Chrome DevTools で、[設定] を開きます。[Experiments] で [Enable Reporting API panel in the Application panel] をクリックします。
DevTools を再読み込みします。
ページを再読み込みします。DevTools が開いているページで生成されたレポートは、Chrome DevTools の [アプリケーション] パネルの [Reporting API] に表示されます。

レポートを一覧表示する Chrome DevTools。 — Chrome DevTools には、ページで生成されたレポートとそのステータスが表示されます。

レポートのステータス

[ステータス] 列には、レポートが正常に送信されたかどうかが表示されます。

ステータス	説明
`Success`	ブラウザがレポートを送信し、エンドポイントが成功コード（`200` または別の成功レスポンスコード `2xx`）を返しました。
`Pending`	ブラウザがレポートの送信を試行している。
`Queued`	レポートは生成されており、ブラウザはレポートを送信しようとしていません。レポートが `Queued` と表示されるのは、次の 2 つのケースのいずれかです。レポートが新しく、ブラウザは送信を試みる前に、さらにレポートが届くかどうかを待っています。レポートが新しいものではない。ブラウザがすでにこのレポートの送信を試みて失敗し、再試行するまで待機している。
`MarkedForRemoval`	しばらく再試行した後（`Queued`）、ブラウザはレポートの送信を停止し、送信するレポートのリストからまもなく削除されます。

レポートは、正常に送信されたかどうかにかかわらず、しばらくすると削除されます。

重要なポイント: Queued ステータスは、送信が失敗したのか、まだ試行されていないのかを正確に示していないため、必ずしも有益な情報とは言えません。短いレポート遅延を使用すると、レポートが Queued のままになっている場合は、送信が失敗している可能性が高いことを示します。

トラブルシューティング

レポートが生成されない、またはエンドポイントに想定どおりに送信されない場合は、この問題をトラブルシューティングするためのヒントをいくつかご紹介します。

レポートが生成されない

DevTools に表示されるレポートは正しく生成されています。目的のレポートがこのリストに表示されない場合は、次の操作を行います。

ポリシーで report-to を確認します。これが誤って構成されている場合、レポートは生成されません。これを修正するには、[ポリシーを編集] に移動します。この問題をトラブルシューティングするもう 1 つの方法は、Chrome の DevTools コンソールを確認することです。コンソールに想定した違反のエラーが表示された場合は、ポリシーが正しく構成されている可能性があります。
このリストには、DevTools が開いているドキュメントに対して生成されたレポートのみが表示されます。たとえば、サイト site1.example にポリシーに違反する iframe site2.example が埋め込まれており、レポートが生成される場合、このレポートは、iframe を独自のウィンドウで開き、そのウィンドウで DevTools を開いた場合にのみ DevTools に表示されます。

レポートは生成されたが、送信されていないか受信されていない

DevTools にレポートが表示されるのに、エンドポイントでレポートを受信できない場合はどうすればよいですか？

重要なポイント: レポートは、特定のサイトではなくブラウザ自体によって帯域外で送信されるため、レポートを含む POST リクエストは、デベロッパーツールの [ネットワーク] パネルに表示されません。

短い遅延を使用してください。レポートが表示されないのは、まだ送信されていないことが原因かもしれません。
Reporting-Endpoints ヘッダーの構成を確認します。問題がある場合、正しく生成されたレポートは送信されません。この場合、DevTools では、レポートのステータスは Queued のままになります（Pending にジャンプしてから、配信が試行されるとすぐに Queued に戻る可能性があります）。このエラーの原因となる一般的な間違いは次のとおりです。
エンドポイントは使用されていますが、構成されていません。例:

間違いのあるコード

 Document-Policy: document-write=?0;report-to=endpoint-1;
 Reporting-Endpoints: default="https://reports.example/default"

Document-Policy 違反レポートは endpoint-1 に送信される必要がありますが、このエンドポイント名は Reporting-Endpoints で構成されていません。

default エンドポイントがありません。サポート終了レポートや介入レポートなど、一部のレポートタイプは default という名前のエンドポイントにのみ送信されます。詳細については、Reporting-Endpoints ヘッダーを構成するをご覧ください。
ポリシーヘッダーの構文に問題（引用符の欠落など）がないか確認します。詳細
エンドポイントが受信リクエストを処理できることを確認します。
- エンドポイントが CORS プリフライトリクエストをサポートしていることを確認します。そうでない場合、レポートを受信できません。
- エンドポイントの動作をテストします。そのためには、レポートを手動で生成する代わりに、ブラウザが送信するリクエストに似たリクエストをエンドポイントに送信して、ブラウザをエミュレートします。次のコマンドを実行します。
```
curl --header "Content-Type: application/reports+json" \
  --request POST \
  --data '[{"age":420,"body":{"columnNumber":12,"disposition":"enforce","lineNumber":11,"message":"Document policy violation: document-write is not allowed in this document.","policyId":"document-write","sourceFile":"https://dummy.example/script.js"},"type":"document-policy-violation","url":"https://dummy.example/","user_agent":"xxx"},{"age":510,"body":{"blockedURL":"https://dummy.example/img.jpg","destination":"image","disposition":"enforce","type":"corp"},"type":"coep","url":"https://dummy.example/","user_agent":"xxx"}]' \
  YOUR_ENDPOINT
```
エンドポイントは、成功コード（200 または別の成功レスポンスコード 2xx）を返す必要があります。返されない場合は、構成に問題があります。

Reporting API を使用してウェブアプリケーションをモニタリングする

概要

ユースケースとレポートタイプ

レポート

認証情報付きレポート

ブラウザがレポートを送信するタイミングと方法

サードパーティとファーストパーティの問題

非推奨の例

ブラウザサポート

Reporting API の使用

レポートの送信先を決定する

オプション 1: 既存のレポートコレクタサービスを使用する

オプション 2: 独自のレポートコレクタを構築して運用する

オプション 3: オプション 1 と 2 を組み合わせる

`Reporting-Endpoints` ヘッダーを構成する

キー（エンドポイント名）

値（URL）

例

ヘッダーの設定場所

ポリシーを編集する

例

レポートの設定をデバッグする

レポートを意図的に生成する

時間の節約

DevTools を使用する

レポートのステータス

トラブルシューティング

レポートが生成されない

レポートは生成されたが、送信されていないか受信されていない

関連する報告メカニズム

レポート専用

`ReportingObserver`

関連情報

Reporting API を使用してウェブ アプリケーションをモニタリングする コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

概要

ユースケースとレポートタイプ

レポート

認証情報付きレポート

ブラウザがレポートを送信するタイミングと方法

サードパーティとファーストパーティの問題

非推奨の例

ブラウザ サポート

Reporting API の使用

レポートの送信先を決定する

オプション 1: 既存のレポート コレクタ サービスを使用する

オプション 2: 独自のレポート コレクタを構築して運用する

オプション 3: オプション 1 と 2 を組み合わせる

Reporting-Endpoints ヘッダーを構成する

キー（エンドポイント名）

値（URL）

例

ヘッダーの設定場所

ポリシーを編集する

例

レポートの設定をデバッグする

レポートを意図的に生成する

時間の節約

DevTools を使用する

レポートのステータス

トラブルシューティング

レポートが生成されない

レポートは生成されたが、送信されていないか受信されていない

関連する報告メカニズム

レポート専用

ReportingObserver

関連情報

Reporting API を使用してウェブアプリケーションをモニタリングする

ブラウザサポート

オプション 1: 既存のレポートコレクタサービスを使用する

オプション 2: 独自のレポートコレクタを構築して運用する

`Reporting-Endpoints` ヘッダーを構成する

`ReportingObserver`