no-referrer-when-downgradeとは?意味と利用方法について解説します

こんにちは、株式会社インディバースの代表の河合大です。

  • リファラーを取得できるようにしていて、no-referrer-when-downgrade というタグを入れろと記載されていた
  • しかしそのHTMLタグの意味を調べても、いまいち意味がわからなかった
  • このタグは何をしているのか知りたい

という方向けに、非エンジニアでもわかるように、

  • no-referrer-when-downgrade の意味
  • no-referrer-when-downgrade ができること
  • no-referrer-when-downgrade の導入方法

について解説していきます。

先に結論です。

  1. <meta name="referrer" content="no-referrer-when-downgrade"/> は、リンク先のページにリファラ情報を原則全て渡すという意味のHTML。
  2. 「原則」というのは、「非https」のリンク先呑みは、リファラを渡さないという意味。
  3. ブラウザはデフォルトで<meta name="referrer" content="strict-origin-when-cross-origin"/> が指定されている。これは「別ドメインへ遷移させる場合は、遷移元のドメインしか渡さない」という意味

no-referrer-when-downgradeとは?

no-referrer-when-downgradeとは、リンク先のページに対して、原則渡すというタグになります。

no-referrer-when-downgradeの実装方法は?

metaタグで入れる方法と、リンクに入れる方法の2つやり方があります。

基本的にアフィリエイトメディアさんであれば、headタグに入れるので良いと思います。

  1. <meta name="referrer" content="no-referrer-when-downgrade"/> をheadタグ内に挿入する
  2. <a href="http://example.com" referrerpolicy="no-referrer-when-downgrade"></a> のように、aタグに個別に入れる

どちらを選ぶかは、こういう基準で考えると良いでしょう。

  1. リンク先全てにリファラ情報を渡してもよい → metaタグで指定
  2. 一部のリンクに絞ってリファラ情報を渡しても良い → aタグで指定

URLの中に個人情報などが含まれる場合は、リファラとして渡すとセキュリティ的に問題がありますが、基本WordPressなどのCMSを利用する場合、URLに個人情報などが含まれるケースはほぼありません。

よって、個人的にはmetaタグで指定したほうが、いちいちリンクに一つ一つ指定しなくてもよいので楽です。

なぜno-referrer-when-downgradeを指定するの?

ブラウザの規定値では、<meta name="referrer" content="strict-origin-when-cross-origin"/> というタグが指定されています。(これはコーディングされているわけではなく、何もコード上になくてもこの設定が指定されています)

このstrict-origin-when-cross-origin は、ブラウザでは、基本的に遷移先にURLを渡す値を絞る設定になっています。具体的にいうと、以下のような指定になっています。

  1. 異なるドメインへ遷移する場合、遷移元のURLはドメインまでしか渡さない
  2. 同一ドメインの場合は遷移元のURLをフルパスで渡す

アフィリエイトメディアの場合、同一ドメインへ遷移させるのではなく、必ず別ドメインへ遷移させることになります。そうすると、上の strict-origin-when-cross-origin では、ドメインしか渡せないのです。

リファラポリシーとは

HTMLタグの中のmetaタグであるReferer-Policy で、リファラ情報をどれだけ含めるかを制御することができるタグとなります。

Referrer-Policy は HTTP ヘッダーで、 (Referer ヘッダーで送られる) リファラー情報をリクエストにどれだけ含めるかを制御します。 HTTP ヘッダーのほかに、 HTML でこのポリシーを設定することもできます。

Mozila

以下のように、headタグの下に指定するタグとなります。

<meta name="referrer" content="ここにリファラポリシー"/>

リファラポリシーの種類とは?

リファラポリシーには、さまざまな種類があります。

  1. no-referrer
  2. no-referrer-when-downgrade
  3. origin
  4. origin-when-cross-origin
  5. same-origin
  6. strict-origin
  7. strict-origin-when-cross-origin
  8. unsafe-url

全ての意味が気になる方は、こちらのリンクから詳細を確認してください。


Referrer-Policy
https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Referrer-Policy

なぜリファラポリシーが存在するの?

“Referrer Policy”, W3C Candidate Recommendation, 2017 によると、このリファラーポリシーでは以下の背景で実装されたようです。原文そのままで、翻訳した形で記載していきます。

  1. プライバシー
  2. セキュリティ
  3. トレースバック

プライバシー

  • 遷移元のサイトから、遷移先のページに、趣味趣向の情報を渡すのは問題があるかもしれないため
  • ただし明示的に伝えたいケースとそうではないケースがあり得る

ソーシャルネットワーキングサイトには、それぞれのユーザーのためのプロフィールページがあり、ユーザーは自分の好きなバンドへのハイパーリンクをプロフィールページに追加します。しかし、ソーシャルネットワーキングサイトは、他のユーザーがこれらのハイパーリンクをたどる際、バンドのウェブサイトにユーザーのプロフィールURLを漏らしたくないかもしれません。なぜなら、プロフィールのURLはプロフィールの所有者の身元を明らかにする可能性があるからです。

しかし、一部のソーシャルネットワーキングサイトでは、リンクがそのソーシャルネットワーキングサイトから発信されたことをバンドのウェブサイトに伝えたいと考えるかもしれませんが、どの特定のユーザーのプロフィールにリンクが含まれていたかは明かさないようにしたいかもしれません。


A social networking site has a profile page for each of its users, and users add hyperlinks from their profile page to their favorite bands. The social networking site might not wish to leak the user’s profile URL to the band web sites when other users follow those hyperlinks (because the profile URLs might reveal the identity of the owner of the profile).

Some social networking sites, however, might wish to inform the band web sites that the links originated from the social networking site but not reveal which specific user’s profile contained the links.

セキュリティ

  • URLに個人情報(セッション識別子)が含まれる場合、その個人情報は渡したくない可能性があり得る(これはおそらくドメインしか渡したくないケースのユースケースが想定されていそうです)
  • ただし、リファラ自体で意味のある機能であり、それを伝えたいケースもあり得るので、渡してもいいケースがあり得る(これは渡せる/渡せないを選べるユースケースを想定していると思います)


ウェブアプリケーションがHTTPSとURLベースのセッション識別子を使用している場合、そのウェブアプリケーションは他のウェブサイト上のHTTPSリソースにリンクしたいと考えるかもしれませんが、URL内のユーザーのセッション識別子を漏らさないようにしたいでしょう。

また、ウェブアプリケーションは、それ自体がある機能を付与するURLを使用する場合があります。リファラーをコントロールすることで、これらの機能付与URLがリファラーヘッダーを通じて漏れるのを防ぐのに役立ちます【CAPABILITY-URLS】。

ただし、機能付与URLが漏れる他の方法が存在し、リファラーをコントロールするだけでは、それらの潜在的な漏洩をすべて抑制することはできないことに注意が必要です。


A web application uses HTTPS and a URL-based session identifier. The web application might wish to link to HTTPS resources on other web sites without leaking the user’s session identifier in the URL.

Alternatively, a web application may use URLs which themselves grant some capability. Controlling the referrer can help prevent these capability URLs from leaking via referrer headers. [CAPABILITY-URLS]

Note that there are other ways for capability URLs to leak, and controlling the referrer is not enough to control all those potential leaks.

トレースバック

  • HTTPSのみでトラックバック(引用されたかの通知)を受け取りたいユースケースがある
  • (書いてはいないですが、逆にHTTPのようなURLの場合はもらいたくない、といった意味が込められているかもしれないです。ここは著者的にもよくわからなかったです)

HTTPSでホストされているブログは、HTTPでホストされている別のブログにリンクし、そのブログからトラックバックリンクを受け取りたいかもしれません。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です