このページは Cloud Translation API によって翻訳されました。

Reporting API v1 に移行する

新しいバージョンの Reporting API をご利用いただけます。機密性が高いため、ブラウザ間でサポートされる可能性が高くなります。

Maud Nalpas

Reporting API は、ユーザーがサイトを使用するときにサイトで発生したエラーを通知します。与えられるものブラウザへの介入、ブラウザのクラッシュ、コンテンツセキュリティポリシー違反、 COOP/COEP 違反、非推奨の警告など。

新しいバージョンの Reporting API をご利用いただけます。新しい API はより無駄がなく、対応しています。

概要

サイトデベロッパー

サイトですでにレポート機能をご利用の場合: 新しいヘッダーを使用して v1 に移行します（Reporting-Endpoints）。ただし、しばらくは以前のヘッダーを維持します（Report-To）。移行: サンプルコードをご覧ください。

今すぐサイトにレポート機能を追加する場合: 新しいヘッダーのみを使用してください。（Reporting-Endpoints）。

いずれの場合も、メールに含まれる可能性のあるすべてのレスポンスに Reporting-Endpoints ヘッダーを設定してください。レポートの生成

レポートサービスデベロッパー

エンドポイントサービスを管理している場合や独自のエンドポイントを運用している場合は、エンドポイントサービスの使用に伴いトラフィックの増加が予想されます。または外部のデベロッパーが Reporting API v1（Reporting-Endpoints ヘッダー）に移行する場合。

詳細とサンプルコードについては、以下をご確認ください。

ネットワークエラーのロギング

注意: ネットワークエラーロギングを使用している場合は、引き続き Report-To（v0）になります。これは、ネットワークエラーロギングが Reporting API v1 でサポートされていないためです。

ネットワークエラーロギングの新しいメカニズムが開発されます。この機能が利用可能になったら、Reporting API v0 からこの新しいメカニズムに切り替えてください。

デモとコード

デモサイト: 新しい Reporting API（v1）
デモサイトのコード

v0 と v1 の違い

変更点

API サーフェスは異なります。

v0（従来版）

 Report-To: { group: "main-endpoint", "max_age": 86400, "endpoints": [ { "url": ... }, { "url": ... }] }, { group: "default-endpoint", "max_age": 86400, "endpoints": [ { "url": ... }, { "url": ... }] }
 Document-Policy: ...; report-to main-endpoint

{0 は、Report-To ヘッダーを使用して名前付きエンドポイントグループを構成し、他のヘッダーの report-to ディレクティブを使用して、これらのエンドポイントグループを参照します。

v1（新規）

 Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"
 Document-Policy: ...; report-to main-endpoint

v1 では、Reporting-Endpoints ヘッダーを使用して名前付き 提供します。v0 と同様に、他のヘッダーで report-to ディレクティブを使用して、これらのエンドポイントグループを参照します。

レポートの範囲は異なります。

v0（従来版）

v0 では、一部のレスポンスにのみレポートエンドポイントを設定できます。同じドキュメントの他のドキュメント（ページ）オリジンではこれらのアンビエントエンドポイントが自動的に使用されます。

v1（新規）

v1 では、生成される可能性のあるすべてのレスポンスに Reporting-Endpoints ヘッダーを設定する必要があります。できます。

どちらの API も同じレポートタイプをサポートしていますが、1 つの例外として、v1 ではネットワークエラーレポートはサポートされていません。詳しくは、移行手順をご覧ください。
v0 はサポートされておらず、複数のブラウザではサポートされません。バージョン 1 は、複数のブラウザに対応できます

これまでと変わらない点

レポートの形式と構造に変更はありません。
ブラウザからエンドポイントに送信されたリクエストは、引き続き Content-type の POST リクエストになります。 application/reports+json。
特定のエンドポイントの特定のレポートタイプへのマッピングは、v0 と v1 の両方でサポートされています。
default エンドポイントのロールは変更されません。
Reporting API v1 は ReportingObserver には影響しません。 ReportingObserver は、すべての観測可能なレポートに引き続きアクセスできます。形式は以下のようになります。あります。

v0 と v1 のすべての違い

	以前の Reporting API（v0） `Report-To` ヘッダー	新しい Reporting API（v1） `Reporting-Endpoints` ヘッダー
ブラウザサポート	Chrome 69 以降と Edge 69 以降。	Chrome 96 以降と Edge 96 以降。Firefox もサポートしています。Safari はオブジェクトに対して何も行いません。ブラウザのシグナルをご覧ください。
エンドポイント	複数のレポートコレクタのいずれかにレポートを送信します（エンドポイントグループごとに複数の URL が定義されます）。	特定のレポートコレクタにレポートを送信します（エンドポイントごとに 1 つの URL のみが定義されます）。
API サーフェス	`Report-To` ヘッダーを使用して、名前付きエンドポイントグループを構成します。	`Reporting-Endpoints` ヘッダーを使用して、名前付きエンドポイントを構成します。
この API で生成できるレポートのタイプ	非推奨介入衝突事故 COOP/COEP Content-Security-Policy レベル 3（CSP Level 3）ネットワークエラーロギング（NEL）で確認できます。 _{レポートタイプについて詳しくは、Reporting API に関する投稿をご覧ください。}	変更なし。ただし、ネットワークエラーロギング（NEL）: 新しい Reporting API（v1）ではサポートされていません。
レポートの範囲	生成元に帰属するものとして扱うことを可能にする技術です。ドキュメントの `Report-To` ヘッダーは、その生成元の他のドキュメント（ページ）に影響します。レポートの `url` フィールドは、引き続きドキュメントごとに異なります。	Document. ドキュメントの `Reporting-Endpoints` ヘッダーは、そのドキュメントにのみ影響します。レポートの `url` フィールドは、引き続きドキュメントごとに異なります。
レポートの分離（バッチ処理）	同じレポートエンドポイントを持つ異なるドキュメント（ページ）やサイト/オリジンがほぼ同時にレポートを生成する場合、それらのドキュメントはまとめてバッチ処理され、同じメッセージでレポートエンドポイントに送信されます。	異なるドキュメント（ページ）のレポートがまとめて送信されることはありません。同じオリジンの 2 つのドキュメント（ページ）が同時にレポートを生成しても、同じエンドポイントではバッチ処理されません。これは、プライバシー攻撃を軽減するためのメカニズムです。同じドキュメント（ページ）のレポートは、まとめて送信される場合があります。
ロードバランシング / 優先度のサポート	○	×

エンドポイントデベロッパー: トラフィックの増加が予想される

独自のサーバーをレポートエンドポイントとして設定している場合、またはそのエンドポイントへのトラフィックが増えることが予想されます。

これは、Reporting API v0 とは異なり、Reporting API v1 ではレポートがバッチ処理されないためです。したがって、アプリケーションデベロッパーが Reporting API v1 への移行を開始すると、レポートの数はエンドポイントサーバーへのリクエストの量は増加する。

アプリケーションデベロッパー: `Reporting-Endpoints`（v1）に移行する

どうすればよいですか。

新しい Reporting API（v1）を使用すると、次のようなメリットがあります ✅:

ブラウザのシグナルはポジティブです。つまり、 v1 ではクロスブラウザサポートが期待できる点に注意が必要です（Chrome と Edge）。
API の方が効率的です。
現在、新しい Reporting API（v1）を中心とするツールを開発中です。

これを踏まえると以下のようになります。

サイトですでに Reporting API v0 と Report-To ヘッダーを使用している場合は、 Reporting API v1（移行手順をご覧ください）。サイトですでにコンテンツセキュリティポリシー違反に関する報告機能を使用する場合は、CSP レポートの移行手順を確認してください。
サイトでまだ Reporting API を使用していない場合にレポート機能を追加する場合: 新しい Reporting API（v1）（Reporting-Endpoints ヘッダー）を使用する。例外が 1 つあり、 : ネットワークエラーロギングを使用する必要がある場合は、Report-To（v0）を使用します。ネットワークエラーのロギング Reporting API v1 ではサポートされていません。ネットワークエラーロギングの新しいメカニズムは、利用可能になるまで、Reporting API v0 を使用してください。ネットワークエラーロギングが必要な場合他のレポートタイプと一緒に使用する場合は、Report-To（v0）と Reporting-Endpoints（v1）の両方を使用します。v0 v1 ではネットワークエラーロギング、v1 ではその他すべてのタイプのレポートが提供されます。

移行手順

この移行の目標は、v0 で取得していたレポートが失われるのを防ぐことです。

ステップ 1（今すぐ実行）: Report-To（v0）と Reporting-Endpoints（v1）の両方のヘッダーを使用します。

これにより、以下が得られます。
- Reporting-Endpoints（v1）を利用した新しい Chrome および Edge クライアントからのレポート。
- Report-To（v0）により古い Chrome および Edge クライアントからレポートされたレポート。
Reporting-Endpoints をサポートするブラウザインスタンスは Reporting-Endpoints を使用します。また、そうでないインスタンスは Report-To にフォールバックします。リクエストとレポートの形式は、比較します。
ステップ 2（今すぐ）:Reporting-Endpoints レポートを生成できます。

v0 では、一部のレスポンスのみにレポートエンドポイントを設定し、他のドキュメントには（ページ）はこの「アンビエント」を使用します提供しますバージョン 1 では、スコープ設定のため、生成される可能性のあるすべてのレスポンスに Reporting-Endpoints ヘッダーを設定する必要があります。できます。
手順 3（後で開始）: すべてまたは大部分のユーザーが新しい Chrome または Edge にアップデートされたらインストール（96 以降）の場合は、Report-To（v0）を削除して Reporting-Endpoints のみを残します。

例外として、ネットワークエラーロギングのレポートが必要な場合は、Report-To は新しいネットワークエラーロギングのメカニズムが備わっています。

移行クックブックのコードサンプルを確認する。

CSP レポートの移行手順

Content-Security-Policy と、違反レポートは次のように設定できます。

report-uri ディレクティブを介した CSP ヘッダーのみ。このプラットフォームは Chrome、Firefox、Safari、Edge。レポートは、コンテンツタイプ application/csp-report で送信されます。 CSP 固有の形式になっている必要がありますこれらのレポートは「CSP レベル 2 レポート」と呼ばれます。そして Reporting API に依存しないでください。
Reporting API の場合は、Report-To ヘッダー（従来版）以降を使用 Reporting-Endpoints（v1）。これは Chrome と Edge でのみサポートされています。レポートリクエストには他の Reporting API リクエストと同じ形式、同じコンテンツタイプの application/reports+json。

最初の方法（report-uri のみ）を使用することは非推奨になりました。2 つ目の方法を使用すると、いくつかのメリットがあります。特に、すべてのレポートタイプに対して 1 つの方法でレポートを設定できるほか、汎用エンドポイントも設定できます（Reporting API やその他を介して生成されたレポートリクエストはすべて同じ形式 application/reports+json であるため）。

ただし、report-to をサポートしているブラウザは限られています。そのため、report-uri は Reporting API のアプローチ（Report-To Reporting-Endpoints 以上）を使用して、複数のブラウザから CSP 違反レポートを取得する必要があります。新しい report-uri と report-to を認識するブラウザ（report-to の場合、report-uri は無視されます）あります。report-uri のみを認識するブラウザでは、report-uri のみが考慮されます。

ステップ 1（今すぐ行う）: まだ追加していない場合は、report-uri と report-to を追加します。 report-uri のみをサポートするブラウザ（Firefox）では report-uri が使用されます。また、サポートreport-to（Chrome、Edge）では report-to を使用します。使用する名前付きエンドポイントを指定するには、 report-to では、Report-To と Reporting-Endpoints の両方のヘッダーを使用します。これにより新旧両方の Chrome および Edge クライアントからのレポートを作成できます。
手順 3（後で開始）: すべてまたは大部分のユーザーが新しい Chrome または Edge にアップデートされたらインストール（96 以降）の場合は、Report-To（v0）を削除して Reporting-Endpoints のみを残します。維持 report-uri のみをサポートしているブラウザのレポートは引き続き表示できます。

これらの手順のコードサンプルについては、CSP レポートの移行をご覧ください。

移行: サンプルコード

概要

以前の Reporting API（v0）を使用して COOP の違反レポートを取得している場合（Cross-Origin-Opener-Policy ヘッダー）、COEP（Cross-Origin-Embedder-Policy）、またはドキュメントポリシー（Document-Policy ヘッダー）: 移行時にこれらのポリシーヘッダー自体を変更する必要はありません。 Reporting API v1 にアップグレードされます。必要なのは、以前の Report-To ヘッダーを新しいヘッダーに移行する必要があります。 Reporting-Endpoints ヘッダー。

以前の Reporting API（v0）を使用して CSP の違反レポートを取得している場合（Content-Security-Policy ヘッダー）、Content-Security-Policy 新しい Reporting API（v1）への移行をご完了ください。

基本的な移行

以前のコード（v0 を使用）

Report-To: { group: "main-endpoint", "endpoints": [ { "url": "https://reports.example/main" }] }, { group: "default-endpoint", "endpoints": [ { "url": "https://reports.example/default" }] }

新しいコード（v1 と v0 の遷移コード）

Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"
Report-To: { group: "main-endpoint", "max_age": 86400, "endpoints": [ { "url": "https://reports.example/main" }] }, { group: "default-endpoint", "max_age": 86400, "endpoints": [ { "url": "https://reports.example/default" }] }

サイトにレポート機能がすでにある場合は、Report-To を一時的に保持してくださいレポートが失われないようにする（ほとんどの Chrome および Edge クライアントがアップデートされるまで）

ネットワークエラーのロギングが必要な場合は、ネットワークエラーのロギングが置き換えられるまで Report-To を保持するなります。

新しいコード（v1 のみ）

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

ほとんどの Chrome クライアントと Edge クライアントが更新され、API v1 がサポートされた後のコードは、次のようになります。

v1 でも、特定のレポートタイプを特定のエンドポイントに送信できます。でも、エンドポイントごとに 1 つの URL のみを指定できます。

すべてのページを監視する

Express などの以前のコード（v0 を使用）

app.get("/", (request, response) => {
  response.set("Report-To", …)
  response.render(...)
});
app.get("/page1", (request, response) => {
  response.render(...)
});

v0 では、一部のレスポンスにのみレポートエンドポイントを設定できます。その他そのオリジンのドキュメント（ページ）は、これらのアンビエントエンドポイントを自動的に使用します。ここで設定したエンドポイントは "/" のすべてのレスポンスに使用されます（page1 など）。

Express などの新しいコード（v1 を使用）

// Use a middleware to set the reporting endpoint(s) for *all* requests.
app.use(function(request, response, next) {
  response.set("Reporting-Endpoints", …);
  next();
});

app.get("/", (request, response) => {
  response.render(...)
});

app.get("/page1", (request, response) => {
  response.render(...)
});

v1 では、すべてのクライアントに Reporting-Endpoints ヘッダーを設定する必要があります。レポートを生成する可能性のあるレスポンスです。

CSP レポートの移行

従来のコード（report-uri のみ）

Content-Security-Policy: ...; report-uri https://reports.example/main

report-uri のみの使用はできなくなりました推奨。コードが上記のような場合は、移行します。以下の新しいコード例（緑色）をご覧ください。

従来のコードを改善して、report-uri と report-to ディレクティブを Report-To（v0）ヘッダー

Content-Security-Policy: ...; report-uri https://reports.example/main; report-to main-endpoint
Report-To: main-endpoint="https://reports.example/main"

こちらの方が優れています。このコードでは、指定します。下位互換性のために、report-uri は引き続き保持されます。複数ブラウザではサポートされない report-to しかし、 report-uri。

ただ、このコードでは Reporting API v0（Report-To ヘッダー）を使用しているため、改善の余地があります。v1 への移行: '新しいコード'例を示します（緑色）。

report-uri、レポートエンドポイント（v1）ヘッダーを含む report-to ディレクティブを含む新しいコード

Content-Security-Policy: ...; report-uri https://reports.example/main; report-to main-endpoint
Reporting-Endpoints: main-endpoint="https://reports.example/main"
Report-To: ...

report-to ディレクティブになるまで、report-uri ディレクティブを report-to ディレクティブと一緒に保持するブラウザ間でサポートされています。ブラウザの互換性表します。

一時的に Reporting-Endpoints と Report-To を一緒に置いてください。Chrome と Edge の訪問者が 96 以上のブラウザバージョンにアップグレードしました。Report-To を削除してください。