このページでは、Referrer-Policy を設定し、受信リクエストでリファラーを使用する際のベスト プラクティスについて説明します。
概要
- 予期しないクロスオリジンの情報漏洩は、ウェブユーザーのプライバシーを侵害します。保護的なリファラー ポリシーが役立ちます。
strict-origin-when-cross-originのリファラー ポリシーの設定を検討してください。リファラーの有用性のほとんどを維持しながら、クロスオリジンでデータが漏洩するリスクを軽減します。- クロスサイト リクエスト フォージェリ（CSRF）保護にリファラーを使用しないでください。代わりに CSRF トークンを使用し、セキュリティを強化するために他のヘッダーを使用します。
Referer と Referrer-Policy の基本
HTTP リクエストには、オプションの Referer ヘッダーを含めることができます。このヘッダーは、リクエストの送信元またはウェブページの URL を示します。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: オリジン、パス、クエリ文字列
一部のポリシーは、コンテキスト（クロスオリジン リクエストか同一オリジン リクエストか、リクエストの宛先がオリジンと同じくらい安全かどうか、またはその両方）に応じて異なる動作をするように設計されています。これは、オリジン間または安全性の低いオリジン間で共有される情報の量を制限しながら、自サイト内のリファラーの豊富さを維持するのに役立ちます。
次の表は、リファラー ポリシーが Referer ヘッダーと 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 には、ポリシーと動作の例の完全なリストが用意されています。
リファラー ポリシーを設定する際の注意点は次のとおりです。
- スキーム（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 月時点
リファラー ポリシーが設定されていない場合、ブラウザはデフォルトのポリシーを使用します。
| ブラウザ | デフォルトの Referrer-Policy / 動作 |
|---|---|
| Chrome |
デフォルトは strict-origin-when-cross-origin です。 |
| Firefox |
デフォルト値は strict-origin-when-cross-origin です。バージョン 93 以降、厳格なトラッキング防止機能とプライベート ブラウジングのユーザーの場合、制限の緩いリファラー ポリシー no-referrer-when-downgrade、origin-when-cross-origin、unsafe-url はクロスサイト リクエストでは無視されます。つまり、ウェブサイトのポリシーに関係なく、クロスサイト リクエストではリファラーが常にトリミングされます。
|
| エッジ |
デフォルトは strict-origin-when-cross-origin です。 |
| Safari |
デフォルトは strict-origin-when-cross-origin と似ていますが、いくつかの違いがあります。詳しくは、
トラッキング防止のトラッキングの防止をご覧ください。 |
リファラー ポリシーを設定するためのベスト プラクティス
サイトのリファラー ポリシーを設定する方法はいくつかあります。
ページ、リクエスト、要素ごとに異なるポリシーを設定できます。
HTTP ヘッダーと meta 要素はどちらもページレベルです。要素の有効なポリシーを決定する優先順位は次のとおりです。
- 要素レベルのポリシー
- ページレベルのポリシー
- ブラウザのデフォルト
例:
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 を使用している場合（使用していない場合は、優先的に対応してください）、ウェブサイトの URL が HTTPS 以外のリクエストで漏洩しないようにする必要があります。ネットワーク上の誰でもこれらを確認できるため、漏洩するとユーザーが中間者攻撃にさらされることになります。ポリシー
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の Referrer-Policy を設定することに同意しているかどうかを確認します。- 短所:
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 の変更: Blink の出荷の目的
- Chrome の変更: ステータス エントリ
- Chrome の変更: 85 ベータ版のブログ投稿
- リファラーのトリミングに関する GitHub スレッド: 各ブラウザの動作
- Referrer-Policy の仕様
すべてのレビュー担当者、特に Kaustubha Govind、David Van Cleve、Mike West、Sam Dutton、Rowan Merewood、Jxck、Kayce Basques の貢献とフィードバックに感謝します。