こんにちは、株式会社インディバースの代表の河合大です。
string-origin-when-cross-originについてよくわからないので調べている- HTMLタグの意味を調べても、いまいち意味がわからなかった
- このタグは何をしているのか知りたい
- メディア上でリファラ情報を別サイトに渡せるようにしたい
という方向けに、非エンジニアでもわかるように、
strict-origin-when-cross-originの意味strict-origin-when-cross-originstrict-origin-when-cross-origin
について解説していきます。
先に結論です。
- ブラウザはデフォルトで
<meta name="referrer" content="strict-origin-when-cross-origin"/>が指定されている。これは「別ドメインへ遷移させる場合は、遷移元のドメイン（厳密にはオリジン）しか渡さない」という意味 <meta name="referrer" content="no-referrer-when-downgrade"/>は、リンク先のページにリファラ情報を原則全て渡すという意味のHTML。- 「原則」というのは、「非https」のリンク先呑みは、リファラを渡さないという意味。
動画でも解説しているので、こちらもご参照ください。
strict-origin-when-cross-originとは？
strict-origin-when-cross-originとは、「リンク先のページに対して、別ドメインであればリファラはドメインまで（厳密にいうとオリジンまで）しか渡さない」という意味のリファラを渡す方針（リファラポリシー）です。
Send the origin, path, and querystring when performing a same-origin request. For cross-origin requests send the origin (only) when the protocol security level stays same (HTTPS→HTTPS). Don’t send the
strict-origin-when-cross-origin (default)Refererheader to less secure destinations (HTTPS→HTTP).
strict-origin-when-cross-originはデフォルトでブラウザに埋め込まれている
strict-origin-when-cross-origin は、基本的にHTMLでページを開く際、何も指定されていなければデフォルトでブラウザに設定されています。
よって、特別メディアの方で別のリファラポリシーを設定しない限りは、デフォルトでstrict-origin-when-cross-originが指定されています。そうすると、上の strict-origin-when-cross-origin では、ドメインしか渡せないのです。
リファラポリシーとは
HTMLタグの中のmetaタグであるReferer-Policy で、リファラ情報をどれだけ含めるかを制御することができるタグとなります。
Mozila
Referrer-Policyは HTTP ヘッダーで、 (Refererヘッダーで送られる) リファラー情報をリクエストにどれだけ含めるかを制御します。 HTTP ヘッダーのほかに、 HTML でこのポリシーを設定することもできます。
以下のように、headタグの下に指定するタグとなります。
<meta name="referrer" content="ここにリファラポリシー"/>
リファラポリシーの種類とは？
リファラポリシーには、さまざまな種類があります。
- no-referrer
- no-referrer-when-downgrade
- origin
- origin-when-cross-origin
- same-origin
- strict-origin
- strict-origin-when-cross-origin
- unsafe-url
全ての意味が気になる方は、こちらのリンクから詳細を確認してください。
Referrer-Policy
https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Referrer-Policy
なぜリファラポリシーが存在するの？
“Referrer Policy”, W3C Candidate Recommendation, 2017 によると、このリファラーポリシーでは以下の背景で実装されたようです。原文そのままで、翻訳した形で記載していきます。
- プライバシー
- セキュリティ
- トレースバック
プライバシー
- 遷移元のサイトから、遷移先のページに、趣味趣向の情報を渡すのは問題があるかもしれないため
- ただし明示的に伝えたいケースとそうではないケースがあり得る
ソーシャルネットワーキングサイトには、それぞれのユーザーのためのプロフィールページがあり、ユーザーは自分の好きなバンドへのハイパーリンクをプロフィールページに追加します。しかし、ソーシャルネットワーキングサイトは、他のユーザーがこれらのハイパーリンクをたどる際、バンドのウェブサイトにユーザーのプロフィール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でホストされている別のブログにリンクし、そのブログからトラックバックリンクを受け取りたいかもしれません。
strict-origin-when-cross-originは、プライバシー保護+セキュアなリファラーポリシー
上記のプライバシー保護の観点や、セキュリティの観点からも、string-origin-when-cross-originというリファラポリシーは、セキュアなリファラポリシーになっています。
実際、個人情報保護の流れから、ほぼ全てのブラウザでも、デフォルトのブラウザの規定値ではstring-origin-when-cross-origin が指定されています。
strict-origin-when-cross-originを解除し、リファラを渡したい場合は？
strict-origin-when-cross-originを解除するためには、デフォルトのリファラポリシーを上書きする必要があります。セキュアかつリファラポリシーを渡す方法としては、
no-referrer-when-downgradeを追加する
という方法になります。
no-referrer-when-downgradeの実装方法は？
metaタグで入れる方法と、リンクに入れる方法の2つやり方があります。
基本的にアフィリエイトメディアさんであれば、headタグに入れるので良いと思います。
<meta name="referrer" content="no-referrer-when-downgrade"/>をheadタグ内に挿入する<a href="http://example.com" referrerpolicy="no-referrer-when-downgrade"></a>のように、aタグに個別に入れる
どちらを選ぶかは、こういう基準で考えると良いでしょう。
- リンク先全てにリファラ情報を渡してもよい → metaタグで指定
- 一部のリンクに絞ってリファラ情報を渡しても良い → 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を渡す値を絞る設定になっています。具体的にいうと、以下のような指定になっています。
- 異なるドメインへ遷移する場合、遷移元のURLはドメインまでしか渡さない
- 同一ドメインの場合は遷移元のURLをフルパスで渡す
アフィリエイトメディアの場合、同一ドメインへ遷移させるのではなく、必ず別ドメインへ遷移させることが多いので、このタグを指定してあげるとリファラが取得できるようになります。
参考：
アフィリエイトのコンバージョンのリファラ取得できるツール
メディアアナリティクスは、SEOアフィリエイトメディア向けのコンバージョン分析サービスです。
- 日次で利用している全ASPの売上を自動更新
- コンバージョンのリファラ取得に対応
- 1記事あたりの売上・PV・CVR・平均単価を一括可視化
といった、SEOアフィリエイトで売上改善を行うために必要な機能がぎゅっと詰まっています。
個人ブロガーから大手メディア様でも利用いただいております。まずは無料トライアルからお試しください！
無料でまずは1ヶ月のトライアルをお試しください
