このページでは、リファラー ポリシーを設定し、受信リクエストでリファラーを使用する際のおすすめの方法について説明します。
まとめ
- 予期しないクロスオリジンの情報漏洩は、ウェブユーザーのプライバシーを損なう。保護リファラー ポリシーが役立ちます。
- 参照 URL ポリシーを
strict-origin-when-cross-origin
に設定することを検討してください。これにより、クロスオリジンでのデータ漏洩のリスクを軽減しながら、リファラーの有用性のほとんどを維持できます。 - クロスサイト リクエスト フォージェリ(CSRF)の保護に参照 URL を使用しないでください。代わりに CSRF トークンを使用し、他のヘッダーを使用してセキュリティを強化してください。
リファラーとリファラー ポリシー(入門編)
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 です。本来のユーザー以外がこれを受け取った場合、悪意のある人物がユーザーのアカウントを乗っ取るおそれがあります。
参照 URL ポリシーを設定すると、サイトからのリクエストに対して使用できる参照データを制限できます。
どのようなポリシーを利用できますか?また、それぞれのポリシーにはどのような違いがありますか?
8 つのポリシーのいずれかを選択できます。ポリシーに応じて、Referer
ヘッダー(および document.referrer
)から取得できるデータは次のようになります。
- データなし(
Referer
ヘッダーがない) - オリジンのみ
- 完全な URL: オリジン、パス、クエリ文字列
一部のポリシーは、コンテキスト(クロスオリジンまたは同一オリジンのリクエスト、リクエストの宛先がオリジンと同程度に安全か、その両方か)に応じて異なる動作をするように設計されています。これは、サイト内でリファラーの豊富さを維持しながら、オリジン間で共有される情報の量や安全性の低いオリジンと共有する情報の量を制限するのに役立ちます。
次の表は、リファラー ポリシーによって、リファラー ヘッダーと 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 では、ポリシーと動作の例の全リストを提供しています。
参照 URL ポリシーを設定する際は、以下の点にご注意ください。
- スキーム(HTTPS と HTTP)を考慮するすべてのポリシー(
strict-origin
、no-referrer-when-downgrade
、strict-origin-when-cross-origin
)は、HTTP オリジンから別の HTTP オリジンへのリクエストを、HTTPS オリジンから別の HTTPS オリジンへのリクエストと同じように処理します。ただし、HTTP は安全性が低くなります。なぜなら、これらのポリシーでは、セキュリティのダウングレードが行われるかどうか、つまりリクエストで暗号化された送信元から暗号化されていない送信元にデータを公開できるかどうか(HTTPS → HTTP リクエストなど)が重要となるためです。HTTP → HTTP リクエストは完全に暗号化されないため、ダウングレードはありません。 - リクエストが同一オリジンである場合、スキーム(HTTPS または HTTP)が同じであるため、セキュリティのダウングレードはありません。
ブラウザのデフォルトのリファラー ポリシー
2021 年 10 月現在
参照 URL ポリシーが設定されていない場合、ブラウザはデフォルトのポリシーを使用します。
ブラウザ | デフォルトの 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 と似ていますが、若干の違いがあります。詳しくは、
トラッキング防止機能によるトラッキングの防止をご覧ください。 |
参照 URL ポリシーの設定に関するベスト プラクティス
サイトのリファラー ポリシーを設定する方法はいくつかあります。
ページ、リクエスト、要素ごとに異なるポリシーを設定できます。
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
ポリシーに従います。
参照 URL ポリシーの確認方法
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 など)に発生します。
代替 URL を定義するには、まず参照 URL のどの部分を使用しているかを分析します。
送信元の IP アドレスのみが必要な場合は、
- ページへのトップレベル アクセス権を持つスクリプトで参照 URL を使用している場合は、
window.location.origin
の代わりに使用できます。 - 利用できる場合は、
Origin
やSec-Fetch-Site
などのヘッダーでOrigin
を返すか、リクエストがクロスオリジンかどうかを記述します。これは、まさに必要とする内容になるかもしれません。
URL の他の要素(パス、クエリ パラメータなど)が必要な場合
- リクエスト パラメータを使用すると、参照 URL を解析する手間を省くことができます。
- ページへのトップレベル アクセス権を持つスクリプトで参照 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
ヘッダーを使用できるかどうかを確認します。これにより、参照 URL を解析することなく、デバッグ目的で必要な情報をより簡単に得られる場合があります。
お支払い
決済機関は、セキュリティ チェックのために、受信リクエストの 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 販売者サイトが HTTPS 決済プロバイダにリダイレクトされると、Referer
はどうなりますか?
HTTPS 決済機関へのリクエストには Referer
は表示されません。ウェブサイトにポリシーが設定されていない場合、ほとんどのブラウザはデフォルトで strict-origin-when-cross-origin
または no-referrer-when-downgrade
を使用するためです。Chrome が新しいデフォルト ポリシーに変更されても、この動作は変更されません。
おわりに
保護参照 URL ポリシーは、ユーザーのプライバシー保護を強化するための優れた方法です。
ユーザーを保護するためのさまざまな手法について詳しくは、安全性と保護に関するコレクションをご覧ください。
リソース
- 「same-site」と「same-origin」について
- 新しいセキュリティ ヘッダー: 参照 URL ポリシー(2017 年)
- MDN のリファラー ポリシー
- リファラー ヘッダー: MDN のプライバシーとセキュリティに関する懸念
- Chrome の変更: Blink インテントを実装する
- Chrome の変更: Blink の発送の意向
- Chrome の変更: ステータス エントリ
- Chrome の変更: 85 ベータ版のブログ投稿
- 参照 URL トリミング GitHub スレッド: 各種ブラウザの動作
- 参照ポリシーの仕様
すべてのレビュアー(特に Kaustubha Govind、David Van Cleve、Mike West、Sam Dutton、Rowan Merewood、Jxck、Kayce Basques)への貢献とフィードバックに感謝します。