リファラーとリファラーポリシーのベストプラクティス
リファラーポリシーを設定し、送信されてくるリクエストにリファラーを使用するためのベストプラクティス。
概要 #
- 予期しないクロスオリジン情報の漏洩は、Web ユーザーのプライバシーに支障をきたします。保護リファラーポリシーが便利です。
strict-origin-when-cross-originリファラーポリシーを設定することをご検討ください。データのクロスオリジンを漏洩するリスクを軽減しながら、リファラーの有用性の多くを保持します。- クロスサイトリクエストフォージェリ (CSRF) 保護にリファラーを使用しないでください。 代わりに CSRF トークンを使用し、セキュリティの追加レイヤーとして他のヘッダーを使用します。
始める前に：
- 「サイト」と「オリジン」の違いがわからない場合は、 「同一サイト」と「同一オリジン」についてをご確認ください。
- 元々仕様にスペルミスがあり、
Refererヘッダーの「R」が抜けています。JavaScript と DOM のReferrer-Policyヘッダーとreferrerのスペルは正しく表記されています。
リファラーとリファラーポリシー 101 #
HTTP リクエストには、リクエストの発信元または Web ページの URL を示す Referer ヘッダーが含まれる場合があります。 Referrer-Policy ヘッダーは、Referer ヘッダーで使用できるデータを定義します。
以下の例では、Referer ヘッダーには、リクエストの発信元となる site-one のページの完全な URL が含まれています。
Referer ヘッダーは、さまざまなタイプのリクエストに存在する可能性があります。
- ユーザーがリンクをクリックしたときのナビゲーションリクエスト
- ブラウザーが画像、iframe、スクリプト、およびページに必要なその他のリソースを要求するときのサブリソース要求。
document.referrer を使用して JavaScript 経由でアクセスすることも可能です。
Referer 値はインサイトを提供する可能性があります。たとえば、分析サービスはこの値を使用して、 site-two.example の訪問者のうち 50% は social-network.exampleから来たと判断することが考えられます。
ただし、パスとクエリ文字列を含む完全な URL がオリジン間をリファラーとして送信される場合、これはプライバシーの阻害となるほか、セキュリティリスクをもたらす可能性があります。以下の URL をご覧ください。
URL＃1 から ＃5 には個人情報が含まれており、場合によっては識別情報や機密情報も含まれます。これらがオリジン間でサイレントに漏洩されると、Web ユーザーのプライバシーが危険にさらされる可能性があります。
URL＃6 は機能 URL で、意図したユーザー以外の人物には渡したくないものです。これが発生した場合、悪意のある攻撃者がこのユーザーのアカウントを乗っ取る可能性があります。
サイトからのリクエストで利用できるリファラーデータを制限するには、リファラーポリシーを設定できます。
利用可能なポリシーは？それぞれの違う点は？ #
8 つのポリシーから 1 つ選択できます。ポリシーに応じて、 Referer ヘッダー (およびdocument.referrer) からは以下のデータを使用できる場合があります。
- データなし (
Refererヘッダーがない) - オリジンのみ
- 完全な URL：オリジン、パス、クエリ文字列
一部のポリシーは、コンテキストに応じて異なる動作をするように設計されています：クロスオリジンまたは同じオリジンのリクエスト、セキュリティ (リクエストの宛先がオリジンと同じくらい安全かどうか)、またはその両方。これは、自分のサイト内のリファラーの豊富さを維持しながら、オリジン間で共有される情報の量を制限したり、安全性の低いオリジンに制限したりするのに役立ちます。
リファラ―ポリシーによってリファラ―ヘッダーと document.referrer の使用できる URL データがどのように制限されるかを以下にまとめています。
MDN で、 ポリシーと動作の例の完全なリストが提供されています。
注意事項：
- スキーム (HTTPS と HTTP) を考慮に入れるすべてのポリシー (
strict-origin、no-referrer-when-downgrade、およびstrict-origin-when-cross-origin) は、HTTP オリジンから別の HTTP オリジンへのリクエストを HTTPS オリジンから別の HTTPS オリジンへのリクエストと同じように処理します (HTTP の安全性が低い場合も例外ではありません)。これらのポリシーについては、セキュリティのダウングレードが発生するかどうか、つまり、リクエストによりデータが暗号化されたオリジンから暗号化されていないオリジンに公開されてしまうかどうかが重要だからです。 HTTP から HTTP へのリクエストは最初から最後まで暗号化されないため、ダウングレードは起こりません。逆に、HTTPS から HTTP リクエストへのリクエストでは、ダウングレードが起こります。 - リクエストのオリジンが同じである場合は、スキーム (HTTPS または HTTP) が同じであるため、セキュリティのダウングレードは起こらないことを意味します。
ブラウザのデフォルトのリファラーポリシー #
2020 年 7 月現在
リファラーポリシーが設定されていない場合は、ブラウザーのデフォルトポリシーが使用されます。
| ブラウザー | デフォルトのReferrer-Policy/動作 |
|---|---|
| クロム | バージョン85でstrict-origin-when-cross-originへの切り替えを計画しています (以前はno-referrer-when-downgrade) |
| Firefox |
|
| 角 |
|
| サファリ | strict-origin-when-cross-originと同様です。詳細については、「トラッキング防止トラッキングの防止」を参照してください。 |
リファラーポリシーの設定：ベストプラクティス #
Objective: strict-origin-when-cross-origin (またはそれ以上に厳密なポリシー) などのプライバシー強化ポリシーを明示的に設定します。
サイトのリファラーポリシーを設定するには、さまざまな方法があります。
ページ、リクエスト、要素ごとに異なるポリシーを設定できます。
HTTP ヘッダーとメタ要素はどちらもページレベルです。要素の有効なポリシーを決定する際の優先順位は次のとおりです。
- 要素レベルのポリシー
- ページレベルのポリシー
- ブラウザーのデフォルト
例：
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 は表示されます。
Web サイトにはどのポリシーを設定する必要がありますか？ #
strict-origin-when-cross-origin （またはそれ以上）などのプライバシー強化ポリシーを明示的に設定します。
なぜ「明示的に」設定するのか？ #
リファラーポリシーが設定されていない場合は、ブラウザーのデフォルトポリシーが使用されます。実際、Web サイトはブラウザーのデフォルト設定に従うことがよくあります。しかし、これは理想的ではありません。理由は次のとおりです。
- ブラウザーのデフォルトポリシーは、ブラウザーとモード (プライベート/シークレット) に応じて、
no-referrer-when-downgrade、strict-origin-when-cross-originのいずれか、またはさらに厳密なポリシーであるため、ブラウザーが異なると Web サイトの動作は予期できないものになります。 strict-origin-when-cross-originなどのより厳密なデフォルトと、クロスオリジンリクエストのリファラートリミングなどのメカニズムを採用しています。ブラウザのデフォルトが変更される前にプライバシー強化ポリシーを明示的にオプトインすると、制御が可能になり、適切と思われるテストを実行できるようになります。
なぜstrict-origin-when-cross-origin (またはより厳密なポリシー) を使うのですか？ #
ポリシーは安全で、プライバシーの強化につながり、かつ便利なものが必要だからです。何が「便利」なのかは、リファラーに何を求めているかによって異なります。
- 安全：Web サイトが HTTPS を使用している場合 (使用していない場合は優先します)、HTTPS 以外の要求で Web サイトの 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 を共有することはありません。したがって、これが必要な場合は、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'});他には何を考慮すべきですか？ #
どのポリシーを使用するかは、Web サイトやユースケースにより異なります。これは、あなた自信やあなたのチーム、お勤め先の企業が決める事です。一部の URLに 識別データまたは機密データが含まれている場合は、保護ポリシーを設定します。
Warning: 機密性が低いと思われるデータでも、ユーザーにとっては機密性が高いものである場合があります。または、単に不要なデータであったり、オリジン間でサイレントにリークするとは思われていないデータである場合もあります。
送信されてくるリクエストのリファラーの使用：ベストプラクティス #
サイトの機能が送信されてくるリクエストのリファラー URL を使用している場合はどうすればよいですか？ #
ユーザーのデータを保護する #
Refererには、個人データや識別データが含まれている可能性があるため、適切に取り扱う必要があります。
受信するRefererは変更される場合があることを覚えておきましょう。 #
送られてくるクロスオリジンリクエストのリファラーを使用することには、制限がいくつかあります。
- リクエスト発信元の実装を一切制御できない場合には、受信する
Refererヘッダー (およびdocument.referrer) について予想を立てることはできません。リクエスト発信元は、いつでもno-referrerポリシー、または一般的にはより厳密なポリシーに切り替えることができます。つまり、Refererからは、それまでよりも少ない量のデータしか取得できなくなります。 - ブラウザには、デフォルトで Referrer-Policy
strict-origin-when-cross-originが使用されることを増えつつあります。これは、これらを送信するサイトにポリシーが設定されていない場合は、受信するクロスオリジンリクエストで (完全なリファラーURLではなく) オリジンのみを受信できることを意味します。 - ブラウザーは
Refererの管理方法を変更する場合があります。たとえば、将来的には、ユーザーのプライバシーを保護するために、クロスオリジンサブリソースリクエストのオリジンへのリファラーを常にトリミングすることを決定することができます。 Refererヘッダー (およびdocument.referrer) には、必要以上のデータが含まれている場合があります。たとえば、リクエストがクロスオリジンであるかどうかだけを知りたいときに、完全な URL が含まれている場合があります。
Referer代替 #
次の場合は、代替案を検討する必要があります。
- サイトの重要な機能は、受信するクロスオリジンリクエストのリファラー URL を使用します。
- および/またはサイトがクロスオリジンリクエストで必要なリファラー URL の一部を受信しなくなった場合。これは、リクエストエミッタがポリシーを変更した場合、またはポリシーが設定されておらず、ブラウザのデフォルトのポリシーが変更された場合に発生します (Chrome 85など)。
代替案を定義するには、最初にリファラーのどの部分を使用しているかを分析します。
オリジンのみが必要な場合 (https://site-one.example)：
- ページへのトップレベルのアクセス権を持つスクリプトでリファラーを使用している場合は、
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 ヘッダーだけを見ても、セキュリティチェックを判断できる信頼性の高い根拠にはなりません。リクエストする側のサイトは、正当なマーチャントであるかどうかは問わず、no-referrer ポリシーを設定できてしまうからです。それにより、支払いプロバイダーは Referer 情報を使用できなくなってしまいます。ただし、支払いプロバイダーは、Referer を見ることで、no-referrer ポリシーを設定していないナイーブな攻撃者なら特定できる可能性があります。したがって、Referer を最初の基本的なチェックとして使用しても構わないでしょう。そうする場合は以下に注意しましょう。
- **
Refererが常に存在すると思ってはいけません。存在する場合は、それに少なくとも含まれるデータ (オリジン) だけをチェックします。**許可されたRefererのリストを設定するときは、オリジンだけが含まれていること、パスは一切含まれていないことを確認します。例:Referer値のリストを設定するときは、パスが含まれておらず、起点のみが含まれていることを確認してください。例:Refererが全く存在しないこと、またはReferer値 (リクエストする側のウェブサイトのオリジン) が存在することを期待することで、マーチャントが設定したReferrer-Policyやマーチャントがポリシーを一切設定していない場合ならブラウザーの動作について何の憶測も立てていないため、不測のエラーを防ぐことになるからです。サイトとブラウザーはともに、受信するリクエストの中身をオリジンだけ残して取り除くことができます。また、Refererを全く送信しないこともできます。 Refererが存在しない場合、またはリファラーが存在し、基本的なReferer発信元チェックが成功した場合は、もう 1 つのより信頼性が高い検証方法を試します (以下を参照)。
より信頼性の高い検証方法とは何ですか？
信頼できる検証方法の 1 つとして、リクエスターに一意のキーを使ってリクエストパラメーターをハッシュ化させるという方法があります。支払いプロバイダーとして、同じハッシュを自分サイドで計算することにより、自分の計算結果と一致した場合にのみ、そのリクエストを受け入れるということができます。
リファラーポリシーを持たない HTTP マーチャントサイトが HTTPS プロバイダーにリダイレクトしたとき、Referer はどうなりますか？
ウェブサイトにポリシーが設定されていない場合、多くのブラウザーではデフォルトで strict-origin-when-cross-origin または no-referrer-when-downgrade が使用されるため、HTTPS を介した支払いプロバイダーへのリクエストには Referer が一切表示されません。また、Chrome が新たに採用したデフォルトのポリシーによって、この動作が変更されることもありません。
Web サイトに HTTP を使用している場合は、 HTTPS に移行します。
結論 #
保護リファラーポリシーは、ユーザーのプライバシーを高める優れた方法です。
ユーザーを保護するさまざまな手法の詳細については、web.dev の Safe and secure コレクションをご覧ください！
Kaustubha Govind、David Van Cleve、Mike West、Sam Dutton、Rowan Merewood、Jxck、Kayce Basques をはじめとする、すべてのレビューアーの貢献とフィードバックに感謝いたします。
リソース #
- 「同一サイト」と「同一オリジン」を理解する
- 新しいセキュリティヘッダー：リファラーポリシー (2017)
- MDN のリファラーポリシー
- MDN のリファラーヘッダー：プライバシーとセキュリティの懸念
- Chrome の変更：Blink Intent to Implement
- Chrome の変更：Blink Intent to Ship
- Chrome の変更：ステータスエントリ
- Chrome の変更：85 件のベータ版ブログ記事
- GitHub スレッドをトリミングするリファラ―：さまざまなブラウザーの機能
- リファラーポリシーの仕様