外部linkでURLを渡したくないときはnoreferrerとReferrer Policyの範囲を分ける

外部siteへlinkするとき、移動元のURLを渡したくない場合は、個別のlinkに付けるnoreferrerと、document全体で扱うReferrer Policyを分けて考えます。どちらを使っても、link先の内容を確認する仕事や、link先へ移動できることまで代わりに保証するものではありません。まず、何のlinkか、URLに渡してよい情報があるかを決めます。

外部linkは、単に別のsiteへ移動させる機能ではありません。公式資料を根拠として示すlink、決済や申込みを外部serviceへ任せるlink、地図や動画を読み込むlinkでは、移動先の役割も渡る情報も違います。すべての外部linkへ同じ設定を付ける前に、どのURLから、どこへ、何のために移動するかを整理します。

W3CのReferrer Policy Working Draftは、documentから外部resourceを取得したり別のpageへ移動したりするときのReferer HTTP headerを、authorが制御する方法を説明しています。同資料では、noreferrer link typeでlinkごとにreferrerを抑制できること、no-referrer policyではheaderを送らないことを示しています。これはWorking Draftであり、browserごとの実装状況は個別に確認が必要です。

link一つの判断とpage全体の判断を分ける

外部linkの扱いは、link先の目的によって変わります。特定の外部pageだけで移動元URLを渡さないなら、そのlinkの設定を確認します。pageから出るrequest全体について方針を決めるなら、documentに適用するReferrer Policyを検討します。個別linkへ必要な判断と、document全体へ影響する判断を同じ変更として扱いません。

たとえば、会員ごとに異なる情報をURLで渡す設計は、referrerを抑制する設定だけで安全になるわけではありません。URLを知る人がアクセスできる仕組みなら、URLの扱い自体を見直す必要があります。noreferrerは、外部へ移動するときのheaderを抑える選択肢であって、URLに置いた情報を保護する唯一の方法ではありません。

URLに問い合わせ内容、氏名、email address、認証に関わる文字列のような情報を入れるかどうかは、link設定より前の設計です。外部へ渡す前に、browserの履歴、共有端末、メール、画面のコピーなど、URLが残る場所を考えます。noreferrerを付けたからURLの扱いを気にしなくてよい、という結論にはなりません。渡してよい情報だけをURLに置くことが先です。

外部linkの目的を先に確認する

外部linkには、公式資料を示すlink、提携先の申込みpageへ送るlink、外部storageの資料を開くlinkなどがあります。先にlinkの目的を書けば、移動元URLを渡すか、link先の表示をどう確かめるかを判断しやすくなります。

説明用の仮例として、会員用pageから外部の申込みserviceへ移動するlinkを置くとします。page URLに会員を推測できる文字列が含まれるなら、外部serviceへそのURLを渡してよいかを確認します。渡したくない理由が明確なら、対象linkでnoreferrerを検討します。そのうえで、link先が正しい申込みpageを開き、利用者へ必要な条件を案内しているかも確認します。

<a href="https://example.net/application/" rel="noreferrer">
  外部の申込みpageを開く
</a>

この記述は、外部linkにnoreferrer link typeを付ける例です。導入前後には、利用者がlink先へ移動できるか、link先の管理者が参照元情報を必要としていないかを確認します。

公式資料へlinkする場合は、移動元URLを渡さないことが必要か、link先の運営者が参照元を確認することが必要かを考えます。外部申込みserviceへ送る場合は、link先が正しいaccountまたは申込みpageを開くか、利用者が戻る方法を理解できるかも確認します。URLを隠すための設定だけに注意を向けると、link先を間違える、古い申込みpageへ送るといった別の問題を見落とします。

Referrer Policyをpage全体へ適用する判断では、外部へのnavigationだけでなく、pageが読み込む外部resourceも対象になることを考えます。表示に必要な画像、script、計測用resourceなど、外部requestの役割は同じではありません。一つの方針を広く付ける前に、対象pageで何が外部へ出ているかを確認します。個別のlinkだけを扱えばよい場合に、document全体の方針まで変える必要はありません。

URLと外部linkをまとめて確認する

設定は、HTMLの一行だけを見て終わりにしません。実際のpage、URL、link先を順に確認します。

1. 外部linkの目的と、link先の管理者を記録する。
2. 移動元URLに外部へ渡したくない情報がないか確認する。
3. linkごとにnoreferrerが必要かを決める。
4. page全体へ同じ方針が必要な場合だけReferrer Policyを検討する。
5. 対象browserでlink先へ移動できるかを確認する。
6. link先URL、設定した理由、確認者、変更日を残す。

browserで確認するときは、linkをクリックして移動できるかだけを見ません。移動元のURLに渡してよい情報だけが含まれるか、link先が意図したpageか、外部siteから戻ったときに利用者が作業を続けられるかを確認します。対象browserで実際に動かない設定は、仕様書だけを読んでも見つかりません。Working Draftにある方針と、利用者が使うbrowserでの動作を分けて確認します。

外部制作会社がtemplateへ設定を加える場合も、domain、page URL、外部serviceのaccount、link先の管理責任はsite側で把握します。設定を委託しても、どのURLを外部へ渡すかという判断までなくなるわけではありません。外部serviceを変更するときは、旧link先、新link先、対象page、確認者を残します。templateに設定だけを残して、どのlinkのための変更か分からなくしないことが引継ぎに役立ちます。

最初の一手は、外部linkを一つ選び、link先と移動元URLを並べて確認することです。全pageへ一度に設定を足す前に、渡す情報とlinkの目的を一組ずつ決めます。noreferrerは個別linkで判断できる選択肢です。Referrer Policyはdocument全体へ影響する方針です。この範囲の違いを確認してから設定します。