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

Maud Nalpas 氏
Maud Nalpas

始める前に:

  • 「site」と「origin」の違いがわからない場合は、「same-site」と「same-origin」について」をご覧ください。
  • Referer ヘッダーに R がありません。これは、仕様における独自のスペルミスが原因です。JavaScript と DOM の Referrer-Policy ヘッダーと referrer のスペルは正しいです。

概要

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

変更点とその理由

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

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

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

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

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

最近まで、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 の場合: リファラー: 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 を使用している場合(優先度を上げておかないと優先する)、HTTPS 以外のリクエストでウェブサイトの URL が漏洩することはありません。これは、ネットワーク上の誰もがアクセスできるため、ユーザーを中間者攻撃にさらす可能性があるためです。
  • 同じオリジン内の Referer ヘッダー値は完全な URL です。

たとえば、https://site-one.example/stuff/detail?tag=red から https://site-one.example/... に送信された同一オリジン リクエスト:

  • strict-origin-when-cross-origin を使用する場合: リファラー: 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 フラグを有効にする方法。
フラグの有効化

これで、ウェブサイトとバックエンドの動作を確認できるようになりました。

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

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

サイトに影響が及ぶ場合は、別の方法を検討

サイトへのリクエストのフルパスまたはクエリ文字列にアクセスするためにリファラーを使用する場合は、いくつかの方法があります。

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

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

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

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

Chrome の変更を考慮したとしても、現時点では、strict-origin-when-cross-origin などの厳密なプライバシー強化ポリシーを設定することをおすすめします。

これにより、ユーザーを保護し、ウェブサイトがどのブラウザでも想定どおりに動作するようになります。ほとんどの場合、ブラウザのデフォルトにサイトを依存させるのではなく、デベロッパーによる制御が可能です。

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

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)に協力とフィードバックに感謝します。

関連情報