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

このページでは、リファラー ポリシーを設定し、受信リクエストでリファラーを使用する際のおすすめの方法について説明します。

まとめ

• 予期しないクロスオリジンの情報漏洩は、ウェブユーザーのプライバシーを損なう。保護リファラー ポリシーが役立ちます。
• 参照 URL ポリシーを strict-origin-when-cross-origin に設定することを検討してください。これにより、クロスオリジンでのデータ漏洩のリスクを軽減しながら、リファラーの有用性のほとんどを維持できます。
• クロスサイト リクエスト フォージェリ（CSRF）の保護に参照 URL を使用しないでください。代わりに CSRF トークンを使用し、他のヘッダーを使用してセキュリティを強化してください。

リファラーとリファラー ポリシー（入門編）

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

次の例では、Referer ヘッダーに、リクエスト送信元の site-one のページの完全な URL が含まれています。

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

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

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

Referer 値から多くのことを学ぶことができます。たとえば、分析サービスでは、この情報を使用して、site-two.example の訪問者の 50% が social-network.example からアクセスしていると判断できます。ただし、パスとクエリ文字列を含む完全な URL が複数のオリジンで Referer で送信されると、ユーザーのプライバシーが危険にさらされ、セキュリティ リスクが生じる可能性があります。

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

URL 6 はケーパビリティ URL です。本来のユーザー以外がこれを受け取った場合、悪意のある人物がユーザーのアカウントを乗っ取るおそれがあります。

参照 URL ポリシーを設定すると、サイトからのリクエストに対して使用できる参照データを制限できます。

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

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

• データなし（Referer ヘッダーがない）
• オリジンのみ
• 完全な URL: オリジン、パス、クエリ文字列

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

次の表は、リファラー ポリシーによって、リファラー ヘッダーと document.referrer から入手できる URL データがどのように制限されるかを示しています。

ポリシーの範囲	ポリシー名	リファラー: データなし	リファラー: オリジンのみ	リファラー: 完全な URL
リクエストのコンテキストを考慮しない	no-referrer	チェック
	origin		チェック
	unsafe-url			チェック
セキュリティ重視	strict-origin	HTTPS から HTTP へのリクエスト	HTTPS から HTTPS、 または HTTP から HTTP へのリクエスト
	no-referrer-when-downgrade	HTTPS から HTTP へのリクエスト		HTTPS から HTTPS、 または HTTP から HTTP へのリクエスト
プライバシー重視	origin-when-cross-origin		クロスオリジン リクエスト	同一オリジン リクエスト
	same-origin	クロスオリジン リクエスト		同一オリジン リクエスト
プライバシーとセキュリティを重視	strict-origin-when-cross-origin	HTTPS から HTTP へのリクエスト	クロスオリジン リクエスト HTTPS から HTTPS または HTTP から HTTP	同一オリジン リクエスト

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

参照 URL ポリシーを設定する際は、以下の点にご注意ください。

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

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

2021 年 10 月現在

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

参照 URL ポリシーの設定に関するベスト プラクティス

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

• HTTP ヘッダーとして
• HTML 内
• JavaScript からリクエスト単位で取得する

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

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 は表示されます。

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

strict-origin-when-cross-origin（またはそれより厳格）のようなプライバシー強化ポリシーを明示的に設定することを強くおすすめします。

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

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

• ブラウザによってデフォルト ポリシーが異なるため、ブラウザのデフォルト設定に依存している場合、サイトはブラウザ間で想定どおりに動作しません。
• ブラウザでは、クロスオリジン リクエストに対して、strict-origin-when-cross-origin などのより厳格なデフォルトや、リファラーのトリミングなどのメカニズムが採用されています。ブラウザのデフォルト設定を変更する前に、プライバシー強化ポリシーを明示的に有効にすることで、テストを適切に管理して実施しやすくなります。

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

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

• 安全: ウェブサイトで HTTPS を使用している場合（そうでない場合を優先）、HTTPS 以外のリクエストでウェブサイトの URL が漏洩しないようにする必要があります。ネットワーク上の誰もがこれらを見ることができるため、漏洩によりユーザーは中間者攻撃にさらされる可能性があります。この問題を解決するには、no-referrer-when-downgrade、strict-origin-when-cross-origin、no-referrer、strict-origin ポリシーを使用します。
• プライバシーの強化: クロスオリジン リクエストの場合、no-referrer-when-downgrade は完全な URL を共有するため、プライバシーの問題が発生する可能性があります。strict-origin-when-cross-origin と strict-origin はオリジンのみを共有し、no-referrer は何も共有しません。これにより、プライバシー強化オプションとして strict-origin-when-cross-origin、strict-origin、no-referrer が残ります。
• 便利: no-referrer と strict-origin は、同一オリジンのリクエストであっても、完全な URL を共有することはありません。完全な 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 を使用する場合のガイドラインを以下に示します。

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

Referer には、プライベート データ、個人データ、個人を特定できるデータが含まれることがあるため、そのように扱ってください。

参照 URL は {referer-can-change} も変更されます

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

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

Referer の代替手段

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

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

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

送信元の IP アドレスのみが必要な場合は、

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

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

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

これらの代替手段を使用できない場合:

• リクエスト エミッター（site-one.example など）がなんらかの構成で必要な情報を明示的に設定するようにシステムを変更できるかどうかを確認します。
  • メリット: site-one.example ユーザーにとって、より明示的でプライバシーの保護が強化され、将来の変化にも対応できます。
  • デメリット: お客様側やシステムのユーザーの負担が増える可能性があります。
• リクエストを発行するサイトが、要素ごとまたはリクエストごとの Referrer-Policy を 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 送信元チェックが成功した場合、より信頼性の高い別の検証方法に進むことができます。

支払いを確実に検証するには、リクエスト元が一意のキーを使用してリクエスト パラメータをハッシュします。決済機関は、お客様側で同じハッシュを計算し、計算に一致する場合にのみリクエストを受け入れます。

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

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

おわりに

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

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

リソース

• 「same-site」と「same-origin」について
• 新しいセキュリティ ヘッダー: 参照 URL ポリシー（2017 年）
• MDN のリファラー ポリシー
• リファラー ヘッダー: MDN のプライバシーとセキュリティに関する懸念
• Chrome の変更: Blink インテントを実装する
• Chrome の変更: Blink の発送の意向
• Chrome の変更: ステータス エントリ
• Chrome の変更: 85 ベータ版のブログ投稿
• 参照 URL トリミング GitHub スレッド: 各種ブラウザの動作
• 参照ポリシーの仕様

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