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

Maud Nalpas
Maud Nalpas

始める前に:

  • 「サイト」と「オリジン」の違いがよくわからない場合は、「同一サイト」と「同一オリジン」についてをご覧ください。
  • 仕様の元のスペルミスにより、Referer ヘッダーに R がありません。Referrer-Policy ヘッダーと JavaScript および DOM の 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 では、バージョン 85 以降、デフォルトのポリシーを no-referrer-when-downgrade から strict-origin-when-cross-origin に切り替える予定です。

つまり、ウェブサイトにポリシーが設定されていない場合、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 の場合: リファラー: https://site-one.example/。

変更されない点

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

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

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

リファラーを使用してサイトへのリクエストのフルパスまたはクエリ文字列にアクセスしている場合は、次のいずれかの方法をおすすめします。

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

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

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

ウェブサイトから送信されるリクエストで Referer を送信するには、サイトにどのようなポリシーを設定する必要がありますか?

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

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

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

Chrome Enterprise について

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

このポリシーは Chrome 88 で廃止されます。

フィードバックを送信

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

すべてのレビュー担当者(特に Kaustubha Govind、David Van Cleve、Mike West、Sam Dutton、Rowan Merewood、Jxck、Kayce Basques)の貢献とフィードバックに感謝します。

リソース