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

Maud Nalpas

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

概要

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

Referer と Referrer-Policy の基本

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 です。意図したユーザー以外がこれを受け取ると、悪意のある行為者がこのユーザーのアカウントを制御できるようになります。

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

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

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

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

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

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

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

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

• スキーム（HTTPS と HTTP）を考慮するすべてのポリシー（strict-origin、no-referrer-when-downgrade、strict-origin-when-cross-origin）は、HTTP のセキュリティが低いにもかかわらず、ある HTTP オリジンから別の HTTP オリジンへのリクエストを、HTTPS オリジンから別の HTTPS オリジンへのリクエストと同じように扱います。これは、これらのポリシーでは、セキュリティのダウングレードが発生するかどうか、つまり、HTTPS → HTTP リクエストのように、リクエストによって暗号化されたオリジンのデータが暗号化されていないオリジンに公開されるかどうかが重要であるためです。HTTP → HTTP リクエストは完全に暗号化されていないため、ダウングレードはありません。
• リクエストが同一オリジンの場合、スキーム（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 にはプライベートなデータ、個人データ、識別データが含まれる可能性があるため、それらのデータとして扱うようにしてください。

リファラーは変更される可能性があります {referer-can-change}

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

• リクエスト エミッタの実装を制御できない場合は、受信した Referer ヘッダー（および document.referrer）について想定することはできません。リクエスト エミッタは、いつでも no-referrer ポリシーに切り替えることができます。一般的には、以前使用していたポリシーよりも厳しいポリシーに切り替えることができます。つまり、以前よりも Referer から受け取るデータが少なくなります。
• ブラウザでは、デフォルトで Referrer-Policy 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 ユーザーのプライバシーの保護が強化され、将来的な変化に対応しやすくなります。
  • デメリット: ユーザー側またはシステム ユーザー側の作業が増える可能性があります。
• リクエストを送信するサイトが、要素ごとまたはリクエストごとのリファラー ポリシーを 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 があり、基本的な Referer オリジン チェックが成功した場合は、別のより信頼性の高い検証方法に進むことができます。

支払いをより確実に検証するには、リクエスト元に一意のキーとともにリクエスト パラメータのハッシュ化を許可します。これにより、決済プロバイダは同じハッシュを計算し、計算結果が一致する場合にのみリクエストを受け付けることができます。

リファラー ポリシーのない HTTP マーチャント サイトが HTTPS 決済機関にリダイレクトされると、Referer はどうなりますか？

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

まとめ

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

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

リソース

• 「同じサイト」と「同じオリジン」について
• 新しいセキュリティ ヘッダー: Referrer Policy（2017 年）
• MDN の Referrer-Policy
• リファラー ヘッダー: MDN のプライバシーとセキュリティに関する懸念事項
• Chrome の変更: 実装する Blink インテント
• Chrome の変更: Blink のリリース意向
• Chrome の変更: ステータス エントリ
• Chrome の変更: 85 ベータ版のブログ投稿
• リファラーの切り捨てに関する GitHub スレッド: 各ブラウザの動作
• Referrer-Policy 仕様

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