リファラーとリファラー ポリシーに関するおすすめの方法

参照 URL ポリシーを設定し、受信リクエストで参照 URL を使用するためのおすすめの方法。

Maud Nalpas
Maud Nalpas

まとめ

  • 予期しないクロスオリジンの情報漏洩は、ウェブユーザーのプライバシーを阻害します。このような場合に役立つのは リファラー保護ポリシーです
  • 参照 URL ポリシーを strict-origin-when-cross-origin に設定することを検討してください。リファラーの有用性の大部分を保持し、クロスオリジンでデータが漏洩するリスクを軽減できます。
  • クロスサイト リクエスト フォージェリ(CSRF)の保護に参照 URL を使用しないでください。代わりに CSRF トークンを使用し、追加のセキュリティ層として他のヘッダーを使用してください。

リファラーとリファラー ポリシー(入門編)

HTTP リクエストには、オプションの Referer ヘッダーを含めることができます。これは、リクエストの送信元の URL またはウェブページ URL を示します。Referrer-Policy ヘッダーは、Referer ヘッダーで使用可能なデータを定義します。

以下の例では、Referer ヘッダーに、リクエストが行われた site-one のページの完全な URL が含まれています。

Referer ヘッダーを含む HTTP リクエスト。

Referer ヘッダーは、さまざまなタイプのリクエストに存在する可能性があります。

  • ナビゲーション リクエスト(ユーザーがリンクをクリックしたとき)
  • サブリソース リクエスト。ブラウザがページに必要な画像、iframe、スクリプトなどのリソースをリクエストしたとき。

ナビゲーションと iframe では、document.referrer を使用して JavaScript を介してこのデータにアクセスすることもできます。

Referer の値は有益な場合があります。たとえば、分析サービスでこの値を使用して、site-two.example の訪問者の 50% が social-network.example からアクセスしていると判断できます。

ただし、パスとクエリ文字列を含む完全な URL が複数のオリジンReferer で送信されると、プライバシーの障害となり、セキュリティ リスクをもたらす可能性があります。こちらの URL をご覧ください。

さまざまなプライバシーとセキュリティのリスクにマッピングされた、パスを含む URL。

URL 1 ~ 5 には個人情報が含まれており、個人を特定できる情報や機密情報が含まれる場合もあります。オリジン間でこれらを通知なく漏洩すると、ウェブユーザーのプライバシーが侵害される可能性があります。

URL 6 はケーパビリティ URL です。意図したユーザー以外の手に負えないようにする必要があります。この場合、悪意のある人物がこのアカウントを乗っ取るおそれがあります。

サイトからのリクエストに使用できるリファラー データを制限するために、リファラー ポリシーを設定できます。

どのようなポリシーを利用できますか?また、それぞれのポリシーにはどのような違いがありますか?

8 つのポリシーのいずれかを選択できます。ポリシーに応じて、Referer ヘッダー(および document.referrer)から取得できるデータは次のようになります。

  • データなし(Referer ヘッダーがない)
  • オリジンのみ
  • 完全な URL: オリジン、パス、クエリ文字列
リファラー ヘッダーと document.referrer に含めることができるデータです。

一部のポリシーは、クロスオリジンまたは同一オリジンのリクエスト、セキュリティ(リクエストの宛先がオリジンと同程度に安全かどうか)、またはその両方など、コンテキストに応じて動作が異なるように設計されています。これは、自身のサイト内でリファラーの豊富さを維持しながら、オリジン間で共有される情報の量や安全性の低いオリジンを制限するのに役立ちます。

参照ポリシーによって、リファラー ヘッダーと document.referrer から入手できる URL データが制限される仕組みの概要は次のとおりです。

セキュリティとクロスオリジンのコンテキストに応じた、さまざまなリファラー ポリシーと動作。

MDN では、ポリシーと動作の例の全リストを提供しています。

注意事項:

  • スキーム(HTTPS と HTTP)を考慮するすべてのポリシー(strict-originno-referrer-when-downgradestrict-origin-when-cross-origin)は、HTTP オリジンから別の HTTP オリジンへのリクエストは、HTTP の安全性が低い場合でも、HTTPS オリジンから別の HTTPS オリジンへのリクエストと同じように処理します。これらのポリシーでは、セキュリティのダウングレードが行われるかどうか、つまりリクエストで暗号化された送信元から暗号化されていない送信元にデータを公開できるかどうかが重要になるためです。HTTP → HTTP リクエストはすべて暗号化されないため、ダウングレードはありません。HTTPS → HTTP リクエストは逆にダウングレードします。
  • リクエストが同一オリジンである場合、スキーム(HTTPS または HTTP)が同じであるため、セキュリティのダウングレードはありません。

ブラウザのデフォルトのリファラー ポリシー

2021 年 10 月現在

参照 URL ポリシーが設定されていない場合は、ブラウザのデフォルトのポリシーが使用されます。

参照者 デフォルトの Referrer-Policy / 動作
Chrome デフォルトは strict-origin-when-cross-origin です。
Firefox デフォルト値は strict-origin-when-cross-origin です。
バージョン 93 以降、厳格なトラッキング保護とプライベート ブラウジングのユーザー: 制限の緩いリファラー ポリシー no-referrer-when-downgradeorigin-when-cross-originunsafe-url は、クロスサイト リクエストに対して無視されます。つまり、ウェブサイトのポリシーに関係なく、クロスサイト リクエストではリファラーが常にトリミングされます。
エッジ デフォルトは strict-origin-when-cross-origin です。
Safari デフォルトは strict-origin-when-cross-origin と似ていますが、いくつかの点で異なります。詳しくは、トラッキング防止機能によるトラッキングの防止をご覧ください。

参照 URL ポリシーの設定: ベスト プラクティス

サイトのリファラー ポリシーを設定する方法はいくつかあります。

ページ、リクエスト、要素ごとに異なるポリシーを設定できます。

HTTP ヘッダーとメタ要素はどちらもページレベルです。要素の有効なポリシーを決定する際の優先順位は次のとおりです。

  1. 要素レベルのポリシー
  2. ページレベルのポリシー
  3. ブラウザのデフォルト

例:

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />

イメージは no-referrer-when-downgrade ポリシーでリクエストされ、このページからの他のすべてのサブリソース リクエストは strict-origin-when-cross-origin ポリシーに従います。

参照 URL ポリシーの確認方法

securityheaders.com は、特定のサイトまたはページで使用しているポリシーを確認するのに便利です。

Chrome、Edge、Firefox のデベロッパー ツールを使用して、特定のリクエストに使用されるリファラー ポリシーを確認することもできます。このドキュメントの作成時点で、Safari には Referrer-Policy ヘッダーは表示されませんが、送信された Referer は表示されます。

リファラーとリファラー ポリシーを表示している Chrome DevTools の [Network] パネルのスクリーンショット。
リクエストが選択された Chrome DevTools の [Network] パネル。

次のうち、どのポリシーをウェブサイトに設定すればよいですか。

概要: strict-origin-when-cross-origin(またはそれより厳格)などのプライバシー強化ポリシーを明示的に設定します。

なぜ「明示的」なのでしょうか。

リファラー ポリシーを設定しない場合は、ブラウザのデフォルトのポリシーが使用されます。実際、ウェブサイトは多くの場合、ブラウザのデフォルトのポリシーに従います。しかし、この方法は理想的ではありません。理由は以下のとおりです。

  • ブラウザのデフォルト ポリシーは、ブラウザとモード(非公開/シークレット モード)に応じて、no-referrer-when-downgradestrict-origin-when-cross-origin、またはそれより厳格になります。そのため、ブラウザが異なってもウェブサイトが想定どおりに動作することはできません。
  • ブラウザでは、クロスオリジン リクエストに対して、より厳密なデフォルト設定(strict-origin-when-cross-origin など)とリファラーのカットなどのメカニズムが採用されています。ブラウザのデフォルト設定が変更される前にプライバシー強化ポリシーを明示的に有効にすることで、テストを適切に管理して実施できるようになります。

strict-origin-when-cross-origin(またはそれより厳格)を使用する理由

安全でプライバシーに配慮した、便利なポリシーが必要です。「有用」の意味は、リファラーに求めることによって異なります。

  • 安全: ウェブサイトで HTTPS を使用している場合(そうでない場合を優先)、HTTPS 以外のリクエストでウェブサイトの URL が漏洩しないようにする必要があります。ネットワーク上の誰もがこれらを見ることができるため、ユーザーを中間者攻撃にさらすことになります。この問題を解決するには、no-referrer-when-downgradestrict-origin-when-cross-originno-referrerstrict-origin ポリシーを使用します。
  • プライバシー強化: クロスオリジン リクエストの場合、no-referrer-when-downgrade は完全な URL を共有します。これはプライバシー強化ではありません。strict-origin-when-cross-originstrict-origin はオリジンのみを共有し、no-referrer は何も共有しません。これにより、プライバシー強化オプションとして strict-origin-when-cross-originstrict-originno-referrer が残ります。
  • 有用: no-referrerstrict-origin は、同一オリジンのリクエストであっても、完全な URL を共有することはありません。そのため、このような場合は strict-origin-when-cross-origin の使用をおすすめします。

つまり、strict-origin-when-cross-origin は一般的に妥当な選択です。

例: strict-origin-when-cross-origin ポリシーを設定する

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />

サーバーサイド(Express など)でも可能です。

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

strict-origin-when-cross-origin(またはより厳密)ですべてのユースケースに対応できない場合は、

この場合は、段階的なアプローチを採用します。たとえば、ウェブサイトに strict-origin-when-cross-origin などの保護ポリシーを設定し、必要に応じて特定のリクエストや HTML 要素にはより制限の少ないポリシーを設定します。

例: 要素レベルのポリシー

index.html:

<head>
  <!-- document-level policy: strict-origin-when-cross-origin -->
  <meta name="referrer" content="strict-origin-when-cross-origin" />
  <head>
    <body>
      <!-- policy on this <a> element: no-referrer-when-downgrade -->
      <a src="…" href="…" referrerpolicy="no-referrer-when-downgrade"></a>
      <body></body>
    </body>
  </head>
</head>

Safari/WebKit では、クロスサイト リクエストに対して document.referrer または Referer ヘッダーが制限されることがあります。詳細をご覧ください。

例: リクエスト レベルのポリシー

script.js:

fetch(url, {referrerPolicy: 'no-referrer-when-downgrade'});

他に検討すべきこと

ポリシーはウェブサイトやユースケースに依存すべきです。これはお客様、チーム、会社次第です。一部の URL に個人を特定できるデータやセンシティブ データが含まれている場合は、保護ポリシーを設定します。

受信リクエストの参照 URL の使用: ベスト プラクティス

受信リクエストの参照 URL がサイトの機能で使用されている場合の対処方法

ユーザーのデータを保護する

Referer には、非公開データ、個人データ、個人を特定できるデータが含まれている可能性があるため、適切に処理してください。

受け取る Referer は変更される場合があります

受信したクロスオリジン リクエストのリファラーを使用する場合、いくつかの制限があります。

  • リクエスト エミッターの実装を制御できない場合、受け取る Referer ヘッダー(および document.referrer)についてなんらかの仮定をすることはできません。リクエスト エミッタは、いつでも no-referrer ポリシーに切り替えるか、より一般的には以前よりも厳格なポリシーに切り替えるかを決定できます。つまり、Referer を介して取得するデータが以前よりも少なくなります。
  • デフォルトでリファラー ポリシー strict-origin-when-cross-origin を使用するブラウザが増えています。つまり、クロスオリジン リクエストの送信元サイトでポリシーが設定されていない場合は、受信したクロスオリジン リクエストで、(完全な参照 URL ではなく)オリジンのみを受け取ることができるようになりました。
  • ブラウザは Referer の管理方法を変更する可能性があります。たとえば、将来的には、ユーザーのプライバシー保護のため、クロスオリジンのサブリソース リクエストのオリジンへの参照を常にカットするようにできます。
  • Referer ヘッダー(および document.referrer)には、必要以上のデータが含まれている場合があります。たとえば、リクエストがクロスオリジンかどうかだけを確認したい場合には、完全な URL を入力します。

Referer の代替手段

次のような場合は、代替手段を検討する必要があります。

  • サイトの基本機能として、受信したクロスオリジン リクエストの参照 URL を使用する。
  • クロスオリジン リクエストで必要な参照 URL の一部をサイトが受け取らなくなった場合。これは、リクエスト エミッタがポリシーを変更した場合や、ポリシーを設定せずにブラウザのデフォルトのポリシーが変更された場合(Chrome 85 など)に発生します。

代替 URL を定義するには、まず参照 URL のどの部分を使用しているかを分析します。

送信元(https://site-one.example)のみが必要な場合:

  • ページへのトップレベル アクセス権を持つスクリプトで参照 URL を使用している場合は、window.location.origin の代わりに使用できます。
  • 利用できる場合は、OriginSec-Fetch-Site などのヘッダーで Origin を表示するか、リクエストがクロスオリジンかどうかを記述します。これは、まさに必要とされているものです。

URL の他の要素(パス、クエリ パラメータなど)が必要な場合:

  • リクエスト パラメータはユースケースに対応しており、参照 URL を解析する手間を省くことができます。
  • ページへのトップレベル アクセス権を持つスクリプトで参照 URL を使用している場合は、window.location.pathname を使用してもかまいません。URL のパス セクションのみを抽出し、引数として渡します。これにより、URL パラメータに含まれる機密情報の可能性がある情報が渡されなくなります。

以下の方法を使用できない場合:

  • リクエスト エミッター(site-one.example)がなんらかの構成で必要な情報を明示的に設定するようにシステムを変更できるかどうかを確認します。メリット: site-one.example ユーザーにとって、より明示的でプライバシーの保護が強化され、将来的な保証にもなります。デメリット: 自社やシステムのユーザーの 負担が増える可能性があります
  • リクエストを発行するサイトが、要素ごとまたはリクエストごとのリファラー ポリシー no-referrer-when-downgrade の設定に同意できるかどうかを確認します。デメリット: site-one.example ユーザーのプライバシー保護に欠ける可能性があります。また、一部のブラウザではサポートされていません。

クロスサイト リクエスト フォージェリ(CSRF)に対する保護

リクエスト エミッターは、no-referrer ポリシーを設定することで、リファラーを送信しないことを常に判断できます(また、悪意のある行為者がリファラーを偽装することもあります)。

主要な保護として CSRF トークンを使用します。保護を強化するには SameSite を使用し、Referer の代わりに、Origin(POST および CORS リクエストで利用可能)や Sec-Fetch-Site(使用可能な場合)などのヘッダーを使用します。

ロギング

Referer に保存されているユーザーの個人情報や機密情報を必ず保護してください。

送信元のみを使用している場合は、Origin ヘッダーを使用してもよいかどうかを確認してください。これにより、参照 URL を解析することなく、デバッグ目的で必要な情報をより簡単に得られる場合があります。

お支払い

決済機関は、セキュリティ チェックのために、受信リクエストの Referer ヘッダーを利用することがあります。

次に例を示します。

  • ユーザーが online-shop.example/cart/checkout で [購入] ボタンをクリックします。
  • online-shop.example は、取引を管理するために payment-provider.example にリダイレクトされます。
  • payment-provider.example は、このリクエストの Referer を、販売者が設定した許可された Referer 値のリストと照合します。リスト内のエントリと一致しない場合、payment-provider.example はリクエストを拒否します。一致する場合、ユーザーは取引に進むことができます。

支払いフローのセキュリティ チェックに関するベスト プラクティス

要約: 決済機関として、Referer は単純な攻撃に対する基本的なチェックとして使用できますが、より信頼性の高い別の検証方法を実装する必要があります。

Referer ヘッダーだけでは、チェックの信頼できる基準にはなりません。正規の販売者であるかどうかに関係なく、リクエスト元のサイトは no-referrer ポリシーを設定して、決済機関は Referer の情報を利用できません。ただし、決済機関は Referer を確認することで、no-referrer ポリシーを設定していない単純な攻撃者を検出できる場合があります。そのため、最初の基本的なチェックとして Referer を使用することを決定できます。その場合:

  • Referer が常に存在するとは限りません。存在する場合は、最低限に含まれるデータ(オリジン)のみを照合します。使用できる Referer 値のリストを設定する際は、パスを含めず、オリジンのみを含めるようにしてください。例: online-shop.example に許可される Referer 値は、online-shop.example/cart/checkout ではなく online-shop.example にする必要があります。そのReferer がまったくないか、リクエストしているウェブサイトのオリジンである Referer 値が想定されている場合、販売者が設定した Referrer-Policy やブラウザの動作(販売者がポリシーを設定していない場合)について想定しないため、予期しないエラーが生じることがなくなります。サイトとブラウザの両方が、受信リクエストで送信された Referer をオリジンのみから削除するか、Referer を一切送信しない場合があります。
  • Referer が存在しない場合、または存在していて、基本的な Referer 送信元チェックに成功した場合は、より信頼性の高い別の検証方法に進みます(以下を参照)。

より信頼性の高いオーナー確認方法は何ですか?

信頼性の高い検証方法の 1 つは、リクエスト元が一意のキーを使用してリクエスト パラメータをハッシュすることです。決済機関は、自社側で同じハッシュを計算し、計算と一致する場合にのみリクエストを受け入れることができます。

リファラー ポリシーのない HTTP 販売者サイトが HTTPS 決済プロバイダにリダイレクトされると、Referer はどうなりますか?

HTTPS 決済プロバイダへのリクエストには Referer は表示されません。ウェブサイトにポリシーが設定されていない場合、ほとんどのブラウザはデフォルトで strict-origin-when-cross-origin または no-referrer-when-downgrade を使用するためです。また、Chrome が新しいデフォルト ポリシーに変更されても、この動作は変わりません。

おわりに

保護参照 URL ポリシーは、ユーザーのプライバシー保護を強化するための優れた方法です。

ユーザーを保護するためのさまざまな手法について詳しくは、web.dev の安全性と安全性に関するコレクションをご覧ください。

リソース