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

Maud Nalpas

このページでは、Referrer-Policy を設定し、受信リクエストで参照元を使用する際のベスト プラクティスについて説明します。

概要

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

参照元と参照元ポリシーの基本

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

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

Referer ヘッダーは、次のようなさまざまなタイプのリクエストに存在する場合があります。

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

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

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

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

URL 6 は機能の URL です。対象のユーザー以外のユーザーがこのコードを受け取ると、悪意のある人物がこのユーザーのアカウントを乗っ取る可能性があります。

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

利用可能なポリシーとその違い

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

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

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

次の表に、参照元ポリシーが Referer ヘッダーと document.referrer から取得できる URL データをどのように制限するかを示します。

MDN には、ポリシーと動作の例の完全なリストが用意されています。

参照元ポリシーを設定する際は、次の点に注意してください。

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

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

2021 年 10 月時点

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

参照元ポリシーを設定する際のベスト プラクティス

サイトの参照元ポリシーを設定するには、次の方法があります。

• 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 ポリシーに従います。

参照元に関するポリシーを確認する方法

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 など）に発生します。

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

オリジンのみが必要な場合は、

• ページへのトップレベル アクセス権を持つスクリプトで参照元を使用している場合は、window.location.origin を使用できます。
• 利用可能な場合は、Origin や Sec-Fetch-Site などのヘッダーから Origin を取得できます。また、リクエストがクロスオリジンかどうかを記述することもできます。これは、まさに必要な情報です。

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 ヘッダーを使用できるかどうかを確認します。これにより、リファラを解析しなくても、デバッグに必要な情報を簡単に取得できます。

お支払い

決済プロバイダは、セキュリティ チェックに受信リクエストの Referer ヘッダーを使用する場合があります。

例:

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

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

支払いプロバイダは、Referer を特定の攻撃に対する基本的なチェックとして使用できます。ただし、Referer ヘッダー自体は、信頼できるチェックの基盤ではありません。リクエスト元のサイトは、正当な販売者であるかどうかにかかわらず、支払いプロバイダが Referer 情報を利用できないようにする no-referrer ポリシーを設定できます。

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 はどうなりますか？

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

まとめ

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

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

リソース

• 「同一サイト」と「同一オリジン」について
• 新しいセキュリティ ヘッダー: Referrer Policy（2017）
• MDN の Referrer-Policy
• Referer ヘッダー: MDN でのプライバシーとセキュリティに関する懸念
• Chrome の変更: Blink インテントの実装
• Chrome の変更: 点滅して出荷する
• Chrome の変更: ステータス エントリ
• Chrome の変更: 85 ベータ版に関するブログ投稿
• Referrer のトリミングに関する GitHub スレッド: 各ブラウザの動作
• 参照 URL ポリシーの仕様

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