Chrome の新しいデフォルトの Referrer-Policy - strict-origin-when-cross-origin

始める前に:

  • [サイト] と [オリジン] の違いがわからない場合は、「同一サイト」と「同一オリジン」についてをご覧ください。
  • Referer ヘッダーには R が 1 つ足りませんが、これは仕様の元のスペルミスによるものです。JavaScript と DOM の Referrer-Policy ヘッダーと referrer は正しくスペルされています。

概要

  • ブラウザは、プライバシーを強化するデフォルトのリファラー ポリシーへと進化しています。これは、ウェブサイトにポリシーが設定されていない場合に適切なフォールバックを提供するためです。
  • Chrome は、85 で strict-origin-when-cross-origin をデフォルトのポリシーとして段階的に有効にする予定です。これにより、別のオリジンからのリファラー値に依存するユースケースに影響が生じる可能性があります。
  • これは新しいデフォルトですが、ウェブサイトは引き続き任意のポリシーを選択できます。
  • Chrome で変更を試すには、chrome://flags/#reduced-referrer-granularity でフラグを有効にします。こちらの デモで、実際の変更を確認することもできます 。
  • リファラー ポリシーだけでなく、ブラウザがリファラーを処理する方法も変更される可能性があるため、注意が必要です。

変更点と理由

HTTP リクエストには、リクエストの送信元の オリジンまたはウェブページ URL を示すオプションの Referer ヘッダーを含めることができます。Referer-Policy ヘッダーは、 Referer ヘッダーで使用できるデータと、宛先の document.referrer のナビゲーションと iframe で使用できるデータを定義します。

サイトからのリクエストの Referer ヘッダーで送信される情報は、設定した Referrer-Policy ヘッダーによって決まります。

図: リクエストで送信されたリファラー。
Referrer-Policy と Referer

ポリシーが設定されていない場合は、ブラウザのデフォルトが使用されます。ウェブサイトは多くの場合、ブラウザのデフォルトに準拠しています。

ナビゲーションと iframe の場合、Referer ヘッダーに存在するデータには、document.referrer を使用して JavaScript からアクセスすることもできます。

最近まで、 no-referrer-when-downgrade はブラウザ全体で広く使用されているデフォルトのポリシーでした。しかし現在、多くのブラウザはプライバシーを強化するデフォルトに移行する段階にあります

Chrome は、デフォルトのポリシーを no-referrer-when-downgrade から strict-origin-when-cross-origin に切り替える予定です(バージョン 85 以降)

つまり、ウェブサイトにポリシーが設定されていない場合、Chrome はデフォルトで strict-origin-when-cross-origin を使用します。任意のポリシーを設定することもできます。この変更は、ポリシーが設定されていないウェブサイトにのみ影響します。

これに伴う影響

strict-origin-when-cross-originプライバシー を強化します。このポリシーでは、 オリジンのみがRefererヘッダーの クロスオリジン リクエストで送信されます。

これにより、パスやクエリ文字列など、完全な URL の他の部分からアクセスできる可能性のある非公開データの漏洩を防ぐことができます。

図: クロスオリジン リクエストの場合、ポリシーに応じてリファラーが送信される。
ポリシーに応じて、クロスオリジン リクエストに対して送信されるリファラー(および document.referrer)

次に例を示します。

https://site-one.example/stuff/detail?tag=red から https://site-two.example/… に送信されるクロスオリジン リクエスト:

  • no-referrer-when-downgrade の場合: Referer: https://site-one.example/stuff/detail?tag=red
  • strict-origin-when-cross-origin の場合: Referer: https://site-one.example/

変更されない点

  • no-referrer-when-downgrade と同様に、strict-origin-when-cross-origin安全 です。リクエストが HTTPS オリジン(安全)から HTTP オリジン(安全でない)に送信される場合、リファラー (Referer ヘッダーと document.referrer)は存在しません。このように、ウェブサイトで HTTPS を使用している場合(使用していない場合は優先的に使用してください)、ウェブサイトの URL が非 HTTPS リクエストで漏洩することはありません。ネットワーク上の誰でも確認できるため、ユーザーが 中間者攻撃を受ける可能性があります。
  • 同じオリジン内では、Referer ヘッダーの値は完全な URL です。

例: 同一オリジン リクエスト(https://site-one.example/stuff/detail?tag=red から https://site-one.example/… に送信):

  • strict-origin-when-cross-origin の場合: Referer: https://site-one.example/stuff/detail?tag=red

影響

他のブラウザとの協議と Chrome 84 で実施された Chrome 独自の テストに基づくと、ユーザーに表示される破損は限定的であると予想されます

完全なリファラー URL を利用できることを前提としたサーバーサイドのロギングや分析は、その情報の粒度が低下する影響を受ける可能性があります。

必要なご対応について

Chrome は、85 で新しいデフォルトのリファラー ポリシーのロールアウトを開始する予定です(ベータ版は 2020 年 7 月、安定版は 2020 年 8 月)。ステータスについては、Chrome のステータス エントリをご覧ください。

変更を理解して検出する

新しいデフォルトの変更内容を実際に確認するには、こちらの デモをご覧ください。

このデモを使用して、実行中の Chrome インスタンスに適用されているポリシーを検出することもできます。

変更をテストして、サイトに影響するかどうかを確認する

Chrome 81 以降では、すでに変更を試すことができます。Chrome でchrome://flags/#reduced-referrer-granularity にアクセスして、フラグを有効にします。このフラグを有効にすると、ポリシーのないすべてのウェブサイトで新しい strict-origin-when-cross-origin デフォルトが使用されます。

Chrome のスクリーンショット: フラグ chrome://flags/#reduced-referrer-granularity を有効にする方法。
[フラグを有効にする]

これで、ウェブサイトとバックエンドの動作を確認できます。

影響を検出するもう 1 つの方法は、ウェブサイトのコードベースでリファラーが使用されているかどうかを確認することです。サーバー上の受信リクエストの Referer ヘッダーを使用しているか、JavaScript の document.referrer を使用しているかを確認します。

サイトへの別のオリジン からのリクエストの参照 URL(具体的にはパスやクエリ文字列)を使用している場合、そのオリジンがブラウザのデフォルトのリファラー ポリシーを使用している(つまり、ポリシーが設定されていない)場合、サイトの一部の機能が破損したり、動作が異なる可能性があります。

サイトに影響する場合は、代替案を検討する

リファラーを使用してサイトへのリクエストの完全なパスまたはクエリ文字列にアクセスしている場合は、次の方法があります。

  • CSRF 保護、ロギング、その他のユースケースに、OriginSec-fetch-Site などの代替技術とヘッダーを使用します。Referer と Referrer-Policy: ベスト プラクティスをご覧ください。
  • 必要に応じて、ユーザーに透過的な特定のポリシーについてパートナーと連携できます。 アクセス制御(ウェブサイトがリファラーを使用して、他のオリジンにリソースへの特定のアクセス権を付与する場合)は、このようなケースに該当する可能性があります。ただし、Chrome の変更により、オリジンは Referer ヘッダー(および document.referrer)で引き続き共有されます。

ほとんどのブラウザはリファラーに関して同様の方向に進んでいます(ブラウザ のデフォルトとその進化については、Referer と Referrer-Policy: ベスト プラクティスをご覧ください)。

サイト全体に明示的なプライバシー強化ポリシーを実装する

ウェブサイトから送信 されるリクエストで送信される Referer は何ですか?つまり、サイトに設定するポリシーは何ですか?

Chrome の変更を考慮しても、strict-origin-when-cross-origin などの明示的なプライバシー強化ポリシー を今すぐ設定することをおすすめします。

これにより、ユーザーが保護され、ウェブサイトがブラウザ間でより予測可能な動作をするようになります。ほとんどの場合、サイトがブラウザのデフォルトに依存するのではなく、制御できるようになります。

ポリシーの設定について詳しくは、Referrer と Referrer-Policy: ベスト プラクティスを ご覧ください。

Chrome Enterprise について

Chrome Enterprise ポリシー ForceLegacyDefaultReferrerPolicy は、エンタープライズ環境で以前のデフォルトのリファラー ポリシー no-referrer-when-downgradeを強制的に適用したい IT 管理者が利用できます。これにより、企業はアプリケーションのテストと更新に十分な時間を確保できます。

このポリシーは Chrome 88 で削除されます。

フィードバックを送信

フィードバックや報告事項はありますか?Chrome のリリース予定に関するフィードバックを送信するか、 質問を@maudnalsにツイートしてください。

レビュー担当者の皆様(特に Kaustubha Govind、David Van Cleve、Mike West、Sam Dutton、Rowan Merewood、Jxck、Kayce Basques)のご協力とフィードバックに感謝いたします。

リソース