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

Maud Nalpas

このページでは、リファラー ポリシーの設定と、 受信リクエストでリファラーを使用します。

概要

• 予期しないクロスオリジンの情報漏洩によりウェブ ユーザーに損害プライバシーを保護する。 保護リファラー ポリシーを使用できます。
• リファラー ポリシーを strict-origin-when-cross-origin に設定することを検討してください。これは、 により、リファラーの有用性の大部分を保ちながら、 データ漏洩を防止できます
• クロスサイト リクエスト フォージェリ（CSRF）からの保護にリファラーを使用しないでください。使用 CSRF トークン その他のヘッダーを使用してセキュリティを強化できます。

参照 URL と参照 URL ポリシー入門

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

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

</ph>

Referer ヘッダーは、さまざまな種類のリクエストに存在する場合があります。

• ナビゲーション リクエスト（ユーザーがリンクをクリックしたとき）。
• サブリソース リクエスト。ブラウザが画像、iframe、スクリプト、 追加することもできます。

ナビゲーションや iframe では、JavaScript を使用して document.referrer。

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

</ph>

URL #1 ～ #5 には個人情報が含まれており、場合によっては機密情報や 保護します。これらを通知なしに送信元間で漏洩すると、不正使用が ウェブユーザーのプライバシーを保護する。

URL 6 はケーパビリティ URL です。誰かが 意図されたユーザーがそれを受け取ったのではない場合、悪意のある人物がコントロールを奪う可能性があります。 このユーザーのアカウントの すべての名前が表示されます

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

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

8 つのポリシーのいずれかを選択できます。ポリシーによっては、 Referer ヘッダー（および document.referrer）から入手できるものは次のとおりです。

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

</ph>

一部のポリシーは、コンテキストに応じて異なる動作をするように設計されています。 クロスオリジン リクエストまたは同一オリジン リクエスト（リクエストの宛先が セキュリティで保護する、あるいはその両方を選べます。これは、表示する情報の量を制限するのに オリジン間や安全性の低いオリジン間で共有され、一方で ご自身のサイト内の参照 URL の情報です。

次の表は、参照 URL ポリシーによって、利用可能な URL データがどのように制限されるかを示しています。 リファラー ヘッダーと document.referrer から読み取ることができます。

MDN はポリシーと動作の完全なリストを提供 例をご覧ください。

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

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

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

2021 年 10 月時点

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

リファラー ポリシーの設定に関するベスト プラクティス

サイトのリファラー ポリシーを設定するには、次のような方法があります。

• HTTP ヘッダーとして使用する
• お客様の HTML
• リクエストごとに JavaScript から作成する

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

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

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 送信しました。

</ph> <ph type="x-smartling-placeholder">

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

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

なぜ「明示的に」行うのですか？

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

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

strict-origin-when-cross-origin（またはより厳格）なのはなぜですか？

プライバシーを保護でき、安全で便利なポリシーが必要です。「役に立った」とは の意味は、リファラーに求める内容によって異なります。

• 安全性: ウェブサイトで 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（またはより厳格）がすべてのユースケースに対応できない場合はどうなるでしょうか。

この場合は、段階的なアプローチを取ります。次のような保護ポリシーを設定します。 ウェブサイトの URL は strict-origin-when-cross-origin で、必要に応じて 制限の緩いポリシーを作成します。

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

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 から受け取るデータが以前より少なくなります。
• 参照 URL ポリシー strict-origin-when-cross-origin を使用するブラウザが増加 できます。つまり、元の Pod にデプロイされず、送信元のみ クロスオリジン リクエストに含まれる完全なリファラー URL（送信側サイトが受信している場合） ポリシーが設定されていません。
• ブラウザによって Referer の管理方法が変更されることがあります。たとえば、ブラウザや デベロッパーは、リファラーを常にクロスオリジンのオリジンにカットして、 ユーザーのプライバシーを保護します。
• Referer ヘッダー（および document.referrer）には、 できます。たとえば、あるかどうかのみを知りたい場合は、完全な URL を クロスオリジンです。

Referer の代替手段

次の場合は、代替手段を検討する必要があるかもしれません。

• サイトに不可欠な機能で、受信したリンクの参照 URL が クロスオリジン リクエストに対応しています。
• 必要な参照 URL の一部を、 作成します。これは、リクエストのエミッターが IP アドレスを ポリシーを設定しておらず、ブラウザのデフォルトのポリシーが変更された場合です。 （Chrome 85 など）。

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

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

• ページへの最上位レベルのアクセス権を持つスクリプトでリファラーを使用している場合、 window.location.origin を使用することもできます。
• 利用可能な場合、 Origin、 Sec-Fetch-Site Origin を返すか、リクエストがクロスオリジンかどうかを ぴったりかもしれません

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

• リクエスト パラメータはユースケースに対応できるため、 リファラーを解析します
• ページへの最上位レベルのアクセス権を持つスクリプトでリファラーを使用している場合、 代わりに window.location.pathname を使用できる場合があります。パスのみを抽出する セクションに追加し、それを引数として渡すことで、 URL パラメータ内の情報は渡されません。

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

• リクエストのエミッターが想定されるようにシステムを変更できるかどうかを確認する （例: site-one.example）。必要な情報を明示的に設定するには、 なんらかの構成で使用します。
  • メリット: site-one.example ユーザーのプライバシー保護がより明確になります。 将来を見据えたソリューションを提供します
  • デメリット: パートナー様やシステムのユーザーの作業が増える可能性があります。
• リクエストの発行元サイトが no-referrer-when-downgrade の要素ごとまたはリクエストごとの Referrer-Policy。
  • デメリット: site-one.example 人のユーザーのプライバシー保護が低くなる可能性があります。 一部のブラウザではサポートされていない可能性があります。

クロスサイト リクエスト フォージェリ（CSRF）対策

リクエストのエミッターは、 no-referrer ポリシーが使用されており、悪意のある人物が参照 URL を偽装する危険性もあります。

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 ヘッダー自体は、 表示されます。リクエスト元のサイトは、正規の販売者であるかどうかに関係なく、 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 販売者サイトにリファラーがない場合の Referer への影響 HTTPS 決済機関にリダイレクトされるのですか？

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

まとめ

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

ユーザーを保護するためのさまざまな手法について詳しくは、 安全かつセキュアな収集

リソース

• 「同一サイト」について「same-origin」です。
• 新しいセキュリティ ヘッダー: 参照 URL ポリシー （2017 年）
• 参照 URL ポリシー: MDN
• 紹介者のヘッダー: プライバシーとセキュリティに関する懸念 MDN
• Chrome の変更: 点滅するインテント 実装
• Chrome の変更: 点滅するインテント 発送
• Chrome の変更: ステータス エントリ
• Chrome の変更: 85 ベータ版 blogpost
• 参照 URL トリミング GitHub スレッド: ブラウザの違い 推奨事項
• 参照 URL ポリシーの仕様

すべてのレビュアー、特に Kaustoneha Govind の貢献とフィードバックに心より感謝いたします。 David Van Cleve、Mike West、Sam Dutton、Rowan Merewood、Jxck、Kayce Basques。