リファラーポリシー

1. はじめに

このセクションは規範的ではありません。

ドキュメントからのリクエストや、そのドキュメントからのナビゲーションは Referer ヘッダーと関連付けられます。noreferrer リンク型を用いることでこのヘッダーを抑制できますが、著者は様々な理由で Referer ヘッダーをより直接的に制御したい場合があります：

1.1. プライバシー

ソーシャルネットワーキングサイトは各ユーザーのプロフィールページを持ち、ユーザーはお気に入りのバンドへのリンクをプロフィールページに追加します。サイトは他ユーザーがそのリンクを辿った際、バンドのウェブサイトにユーザーのプロフィールURLが漏れることを望まない場合があります（プロフィールURLがプロフィール所有者の身元を明らかにする可能性があるため）。

しかし一部のソーシャルネットワーキングサイトは、バンドのウェブサイトにリンク元がそのソーシャルネットワーキングサイトであることを伝えたいが、どのユーザーのプロフィールからのリンクかは明かしたくない場合もあります。

1.2. セキュリティ

ウェブアプリケーションがHTTPSおよびURLベースのセッション識別子を利用している場合、他サイトのHTTPSリソースへのリンク時にユーザーのセッション識別子がURLから漏れることを防ぎたいことがあります。

また、ウェブアプリケーションがURL自体に何らかの権限を付与している場合、リファラーの制御によってこれらの権限付きURLがリファラーヘッダー経由で漏洩するのを防ぐことができます。 [CAPABILITY-URLS]

ただし、権限付きURLが漏洩する方法は他にもあるため、リファラーの制御だけでは全ての漏洩を防ぐことはできません。

1.3. トラックバック

HTTPSでホストされたブログが、HTTPでホストされたブログにリンクし、トラックバックリンクを受け取りたい場合があります。

2. 主な概念と用語

リファラーポリシー

リファラーポリシーは、フェッチによるサブリソース取得、プリフェッチ、ナビゲーション時に Referer ヘッダーを生成するアルゴリズムを変更します。本書では各リファラーポリシーごとの挙動を定義します。

全ての environment settings object は リファラーポリシー取得アルゴリズムを持ち、その リクエストの client がその environment settings object となる場合、デフォルトで使われます。

同一オリジンリクエスト

Request request が 同一オリジンリクエストとなるのは、request の origin と request の current url の origin が the same である場合です。

クロスオリジンリクエスト

Request が 同一オリジン でない場合は クロスオリジンリクエストです。

3. リファラーポリシー

リファラーポリシー は空文字列、"no-referrer"、 "no-referrer-when-downgrade"、"same-origin"、 "origin"、"strict-origin"、 "origin-when-cross-origin"、 "strict-origin-when-cross-origin"、または "unsafe-url" です。

enum ReferrerPolicy {
  "",
  "no-referrer",
  "no-referrer-when-downgrade",
  "same-origin",
  "origin",
  "strict-origin",
  "origin-when-cross-origin",
  "strict-origin-when-cross-origin",
  "unsafe-url"
};

各リファラーポリシーの詳細は以下で説明します。それらの効果を評価するための詳細なアルゴリズムは、§5 Fetchとの統合および§8 アルゴリズムセクションで示されています。

注: environment settings object のリファラーポリシーは、その environment settings object が request client として使用される場合のリクエストに対するデフォルトの基準ポリシーを提供します。このポリシーは、 noreferrer リンク型などの仕組みによって特定のリクエストで強化されることがあります。

3.1. "no-referrer"

最も単純なポリシーは "no-referrer" であり、特定の request client から任意の origin へのリクエストにリファラー情報を一切送信しないことを指定します。ヘッダー自体が完全に省略されます。

3.2. "no-referrer-when-downgrade"

"no-referrer-when-downgrade" ポリシーは、TLSで保護された environment settings object から 潜在的に信頼できるURL へのリクエストや、client が 非TLS保護されている場合は、任意の origin へのリクエストに完全なURLを送信します。

一方、TLS保護された client から非潜在的に信頼できるURLへのリクエストには、リファラー情報は含まれません。 Referer HTTPヘッダーは送信されません。

この動作は、特にポリシーが指定されていない場合のユーザーエージェントのデフォルト動作です。

3.3. "same-origin"

"same-origin" ポリシーは、特定の client から 同一オリジンリクエストを行う際、リファラーとして使用するために 加工された完全なURLを送信することを指定します。

クロスオリジンリクエストの場合は、リファラー情報は含まれず、 Referer HTTPヘッダーは送信されません。

3.4. "origin"

"origin" ポリシーは、特定の request client から 同一オリジンリクエストおよびクロスオリジンリクエストを行う際、オリジンのASCII直列化のみをリファラー情報として送信することを指定します。

注: オリジンの直列化は https://example.com のようになります。ユーザーエージェントは Referer ヘッダーに有効なURLを送信するため、オリジンの末尾に U+002F SOLIDUS（"/"）文字（例：https://example.com/）を付加します。

注: "origin" ポリシーは、HTTPSリファラーのオリジンを暗号化されていないHTTPリクエストでネットワーク上に送信してしまいます。 この懸念には "strict-origin" ポリシーが対応しています。

3.5. "strict-origin"

"strict-origin" ポリシーは、リクエストを行う際に オリジンのASCII直列化を送信します:

• TLSで保護された environment settings object から 潜在的に信頼できるURL へのリクエスト
• 非TLS保護された environment settings objects から任意の origin へのリクエスト

TLS保護された request client から非潜在的に信頼できるURLへのリクエストには、リファラー情報は含まれません。 Referer HTTPヘッダーは送信されません。

3.6. "origin-when-cross-origin"

"origin-when-cross-origin" ポリシーは、特定の request client から 同一オリジンリクエストを行う際は、リファラー用に加工された完全なURLをリファラー情報として送信し、クロスオリジンリクエストの場合は オリジンのASCII直列化のみをリファラー情報として送信します。

注: "origin-when-cross-origin" ポリシーでは、プロトコルのアップグレード（例えば http://example.com/ から https://example.com/ へのリクエスト）も クロスオリジンリクエストとみなします。

注: "origin-when-cross-origin" ポリシーは、HTTPSリファラーのオリジンを暗号化されていないHTTPリクエストにも送信してしまいます。この懸念には "strict-origin-when-cross-origin" ポリシーが対応しています。

3.7. "strict-origin-when-cross-origin"

"strict-origin-when-cross-origin" ポリシーは、特定の request client から 同一オリジンリクエストを行う際は、リファラー用に加工された完全なURLをリファラー情報として送信し、クロスオリジンリクエストの場合は下記条件で オリジンのASCII直列化のみを送信します:

• TLSで保護された environment settings object から 潜在的に信頼できるURL へのリクエスト
• 非TLS保護された environment settings objects から任意の origin へのリクエスト

TLS保護された client から非潜在的に信頼できるURLへのリクエストには、リファラー情報は含まれません。 Referer HTTPヘッダーは送信されません。

3.8. "unsafe-url"

"unsafe-url" ポリシーは、特定の client から 同一オリジンリクエストおよびクロスオリジンリクエストの両方に対し、リファラー用に加工された完全なURLを必ず送信することを指定します。

注: このポリシー名が示す通り、これは危険です。このポリシーは TLSで保護されたリソースのオリジンやパスを非セキュアなオリジンに漏らします。機微なドキュメントにこのポリシーを設定する場合は十分に影響を考慮してください。

3.9. 空文字列

空文字列 "" は リファラーポリシーが存在しないことに対応し、他の場所で定義されているリファラーポリシーにフォールバックします。もし上位のポリシーがなければ、"no-referrer-when-downgrade"にデフォルトで切り替わります。 このデフォルト化は§8.3 リクエストのリファラー決定アルゴリズムで行われます。

4. リファラーポリシーの配信

リクエストのリファラーポリシーは、以下の5つの方法のいずれかで配信されます：

• Referrer-Policy HTTPヘッダーによる配信（§4.1 Referrer-Policyヘッダーによる配信で定義）。
• meta 要素の name 属性にreferrerを指定して配信。
• referrerpolicyコンテンツ属性を a、 area、 img、 iframe、 または link要素に指定して配信。
• noreferrer リンク関係を a、 area、 または link要素に指定して配信。
• 暗黙的に、継承による配信。

4.1. Referrer-Policyヘッダーによる配信

Referrer-Policy HTTP ヘッダーは、ユーザーエージェントがリクエスト時にどのリファラー情報を含めるべきか判断する際に適用するリファラーポリシーを指定します。また、保護されたリソースのコンテキストから作成される閲覧コンテキストにも適用されます。 ヘッダー名と値の構文は、以下のABNF構文で示されます：

"Referrer-Policy:" 1#policy-token

policy-token   = "no-referrer" / "no-referrer-when-downgrade" / "strict-origin" / "strict-origin-when-cross-origin" / "same-origin" / "origin" / "origin-when-cross-origin" / "unsafe-url"

注: このヘッダー名はHTTPのRefererヘッダーの綴り間違いとは異なります。

§5 Fetchとの統合および§6 HTMLとの統合でReferrer-Policyヘッダーの処理方法を説明します。

Referrer-Policy: no-referrer

<a href="http://example.com" referrerpolicy="origin">

7. CSSとの統合

CSS標準は、スタイルシートから参照されたリソースをどのようにフェッチするかについては規定していません。ただし、実装ではスタイルシートから開始されるリクエストのリファラー関連プロパティを以下のように設定すべきです：

1. CSS宣言ブロックがリクエストの責任を持つ場合は、 リファラーをブロックのowner nodeのノードドキュメントのURLに、リファラーポリシーをブロックのowner nodeのノードドキュメントのリファラーポリシーに設定する。
2. CSSスタイルシートがリクエストの責任を持ち、 そのlocationがnullでない場合は、 リファラーをそのlocationに、リファラーポリシーをリファラーポリシーに設定する。

   この仕様では、CSSスタイルシートが`Referrer-Policy`ヘッダーを処理し、リファラーポリシーをDocumentと同様に保存する必要があります。

3. それ以外の場合、CSSスタイルシートのlocationがnullの場合は、 リファラーをそのowner nodeのノードドキュメントのURLに、リファラーポリシーをブロックのowner nodeのノードドキュメントのリファラーポリシーに設定する。

注: リクエストのリファラーとリファラーポリシーの値は、 特定のリクエスト作成時点の値に基づいて設定されます。ドキュメントのリファラーポリシーが生存期間中に変更された場合、インラインスタイルシートリクエストに関連付けられるポリシーも変更されます。

8. アルゴリズム

8.1. Referrer-Policy ヘッダーからリファラーポリシーを解析する

Response response が与えられたとき、以下の手順は response の `Referrer-Policy` ヘッダーに従って リファラーポリシーを返します:

1. policy-tokens を、パースした `Referrer-Policy` の response の ヘッダーリストの結果とする。
2. policy を空文字列とする。
3. policy-tokens 内の各 token について、token が リファラーポリシー であり、かつ空文字列でない場合、policy を token に設定する。

   注: このアルゴリズムが複数のポリシー値をループするのは、§11.1 未知のポリシー値で説明されているように、古いユーザーエージェント向けのフォールバックを含めて新ポリシー値を展開できるようにするためです。

4. policy を返す。

8.2. リダイレクト時の request のリファラーポリシー設定

request request および response actualResponse が与えられたとき、このアルゴリズムは actualResponse の Referrer-Policy ヘッダー（あれば）に従って request の関連付けられた リファラーポリシーを更新します。

1. policy を actualResponse に対して §8.1 Referrer-Policyヘッダーからリファラーポリシーを解析する を実行した結果とする。
2. policy が空文字列でなければ、request の関連リファラーポリシーを policy に設定する。

8.3. request のリファラー決定

Request request が与えられたとき、以下の手順で関連付けられた リファラーポリシーを調べ、送信すべきリファラー情報（`no referrer` またはURL）を返します:

1. policy を request の関連 リファラーポリシーとする。
2. environment を request の client とする。
3. request の referrer の値に応じて分岐する:

   "client"

   1. environment の global object が Window オブジェクトなら
      1. document を environment の 関連付けられた Document とする。
      2. document の origin が 不透明オリジンなら no referrer を返す。
      3. document が iframe srcdocドキュメントなら document を document の 閲覧コンテキストの 閲覧コンテキスト コンテナ の ノードドキュメントとする。
      4. referrerSource を document の URLとする。
   2. それ以外の場合、referrerSource を environment の 作成URLとする。

   URL

   referrerSource を request の referrerとする。

   注: request の referrer が "no-referrer" の場合、Fetchはこのアルゴリズムを呼び出しません。

4. referrerURL を referrerSource をリファラー用に加工した結果とする。
5. referrerOrigin を referrerSource をリファラー用に加工（origin-only flag を true）した結果とする。
6. policy の値に応じて以下を実行する:

   "no-referrer"

   no referrer を返す

   "origin"

   referrerOrigin を返す

   "unsafe-url"

   referrerURL を返す。

   "strict-origin"

   1. environment が null でなければ:
      1. environment が TLS保護されていて、かつ request の current URL が 潜在的に信頼できるURLでない場合、no referrer を返す。
   2. referrerOrigin を返す。

   "strict-origin-when-cross-origin"

   1. request が 同一オリジンリクエストなら referrerURL を返す。
   2. environment が null でなければ:
      1. environment が TLS保護されていて、かつ request の current URL が 潜在的に信頼できるURLでない場合
         1. no referrer を返す。
   3. referrerOrigin を返す。

   "same-origin"

   1. request が 同一オリジンリクエストなら referrerURL を返す。
   2. それ以外の場合、no referrer を返す。

   "origin-when-cross-origin"

   1. request が クロスオリジンリクエストなら referrerOrigin を返す。
   2. それ以外の場合、referrerURL を返す。

   "no-referrer-when-downgrade"

   1. environment が null でなければ:
      1. environment が TLS保護されていて、かつ request の current URL が 潜在的に信頼できるURLでない場合、no referrer を返す。
   2. referrerURL を返す。

   注: Fetchはこのアルゴリズムを呼び出す前に request の リファラーポリシーが空文字列でないことを保証します。

8.4. リファラー用に url を加工する

URL の一部は `Referer` ヘッダー値として送信する際に含めてはなりません。URL のフラグメント、ユーザー名、パスワードは送信前に除去すべきです。 このアルゴリズムは origin-only flag を受け取ります。デフォルトは false です。true の場合はパスとクエリも除去し、スキーム・ホスト・ポートだけが残ります。

1. url が null なら no referrer を返す。
2. url の scheme が ローカルスキームなら no referrer を返す。
3. url の ユーザー名 を空文字列に設定する。
4. url の パスワード を null に設定する。
5. url の フラグメント を null に設定する。
6. origin-only flag が true なら:
   1. url の パス を null に設定する。
   2. url の クエリ を null に設定する。
7. url を返す。

9. プライバシーに関する考慮事項

9.1. ユーザーコントロール

この仕様の内容は、ユーザーエージェントが `Referer` ヘッダーによって送信される情報を変更できるオプションをユーザーに提供することを妨げるものではありません。たとえば、ユーザーエージェントはページ上の有効なリファラーポリシーに関わらず、ユーザーにリファラーヘッダーを完全に抑制することを許可してもかまいません。

10. セキュリティに関する考慮事項

10.1. 情報漏洩

リファラーポリシーのうち、"origin"・"origin-when-cross-origin"・"unsafe-url"は、それぞれ安全なサイトのオリジンやURLを非安全な通信路で漏洩する可能性があります。

それでもこれら3つのポリシーが仕様に含まれている理由は、サイトが安全な通信路（セキュアトランスポート）へ移行する際の障壁を下げるためです。

デフォルトポリシー以上の情報を漏洩したくない著者は、代わりに"same-origin"・"strict-origin"・"strict-origin-when-cross-origin"・"no-referrer"のポリシー状態を使用してください。

10.2. より緩いポリシーへのダウングレード

仕様では、たとえば "no-referrer" から "unsafe-url" へのような、より緩いポリシーへのダウングレードを禁じていません。

一方で、どのポリシーが全ての組み合わせにおいてより厳格かは明確ではありません。たとえば、"no-referrer-when-downgrade" は非安全な通信路では一切情報を漏洩しませんが、"origin"は漏洩します。後者はクロスオリジンのナビゲーションではより少ない情報しか漏洩しません。

また、より緩いポリシーを設定できることで、§11.1 未知のポリシー値で述べたような安全なフォールバックを著者が定義できる利点もあります。

11. 著者向けの考慮事項

11.1. 未知のポリシー値

§8.1 Referrer-Policyヘッダーからリファラーポリシーを解析するや meta のreferrer アルゴリズムに記載の通り、未知のポリシー値は無視され、複数のソースでリファラーポリシーが指定された場合は一番最後の値が使用されます。これにより新しいポリシー値の展開が可能になります。

ただしこの挙動はreferrerpolicy属性には適用されません。著者はreferrerpolicy属性の値を動的に設定・取得することで、特定のポリシー値がサポートされているか検出できます。

12. 謝辞

この仕様はAdam Barth氏とJochen Eisinger氏の Meta referrer 文書を大いに参考にしています。