Referrer-Policyは、リンク遷移や外部リソース取得時に送られるReferer（リファラ）ヘッダーの内容を制御し、URLのパスやクエリが外部へ漏れるリスクを減らす仕組みです。

本記事では、ReferrerとRefererの違いを押さえたうえで、no-referrerやstrict-origin-when-cross-originなど各値の挙動を比較し、HTTPヘッダー／meta／referrerpolicy属性での設定方法、計測との両立を含むベストプラクティスまでまとめて解説します。

Referrer-Policyの設定方法を知りたい方は是非最後までご覧ください。

Referrer-Policyとは？
- Refererヘッダーとは？
- Refererヘッダーをどのように制御する？
Referrer-Policyの設定値一覧
Referrer-Policyの設定方法まとめ：ヘッダー / meta / 属性
Referrer-Policyベストプラクティス：安全性と計測を両立する選び方
まとめ

Referrer-Policyとは？

Referrer-Policyは、ページ遷移や画像・JavaScript読み込み時に送られるReferer（参照元）ヘッダーの内容を制御する仕組みで、URLのパスやクエリが外部に漏れるのを防ぎます。

Refererヘッダーとは？

Referer（参照元）ヘッダーとは、ユーザーがどのページからリンクをクリックして現在のページにアクセスしたのかを、ブラウザがHTTPリクエストに含めて送信する情報です。

たとえば検索結果や他サイトのリンク経由でアクセスした場合、そのURLがサーバー側に伝わります。これによりアクセス解析や流入元の把握が可能になる一方、URLに個人情報や内部パスが含まれていると、意図せず外部サイトへ漏れるリスクもあります。

Refererヘッダーをどのように制御する？

Referrer-PolicyはHTTPレスポンスヘッダーやHTMLのmetaタグで指定でき、「送らない」「同一オリジンのときだけ送る」「HTTPSからHTTPへは送らない」など細かな挙動を選択できます。

これにより、アクセス解析に必要な情報を残しつつ、URLに含まれる機密情報が外部サイトへ漏れるのを防ぐことが可能になります。

Referrer-Policyの設定値一覧

Referrer-Policyには設定できる値が複数あり、値によって制御できる内容が変わります。

全ディレクティブ一覧

ポリシーの中身を決める設定値のことをディレクティブといいます。

Referrer-Policyにおけるディレクティブを一覧化すると、下のようになります。

ディレクティブ	送るRefererのイメージ（要点）
`no-referrer`	一切送らない
`no-referrer-when-downgrade`	HTTPS→HTTP以外は送る（多くの既定）
`origin`	常にオリジンのみ（`https://example.com/`）
`origin-when-cross-origin`	同一オリジンは全文、別オリジンはオリジンのみ
`same-origin`	同一オリジンのみ送る
`strict-origin`	同等以上の安全な遷移のみオリジン送信、downgradeは送らない
`strict-origin-when-cross-origin`	同一は全文、別は原則オリジン、downgradeは送らない
`unsafe-url`	常に全文URLを送る（漏えいリスク大）

no-referrer：Refererを完全に送らない（使いどころと注意）

no-referrer は、ブラウザがRefererヘッダーを一切送信しない設定です。

Referrer-Policy: no-referrer

上の様に設定すると、外部サイトへの遷移時にURL情報が完全に遮断されるため、パラメータや内部パスの漏えいを確実に防げます。

一方で、アクセス解析や外部サービス連携では流入元が分からなくなる点に注意が必要です。管理画面や個人情報を扱うページで有効です。

no-referrer-when-downgrade：HTTPS→HTTPで送らない（旧デフォルトの考え方）

no-referrer-when-downgradeは、HTTPS→HTTPSやHTTP→HTTPではRefererを送る一方、HTTPS→HTTPの「ダウングレード」時だけ送らない方式です。

Referrer-Policy: no-referrer-when-downgrade

上のように、暗号化ページのURLが平文HTTPに漏れるのを防ぐ意図で、昔はブラウザのデフォルト挙動として設定されていました。ただし外部へのフルURL送信は起こり得るため、より厳格な値も検討されます。

strict-origin / strict-origin-when-cross-origin：安全性と実用性の折衷

strict-originとstrict-origin-when-cross-originは、Refererの漏えいを抑えつつ実用性も確保する設定です。

Referrer-Policy: strict-origin
Referrer-Policy: strict-origin-when-cross-origin

strict-origin は常にオリジンのみを送信し、HTTPSからHTTPへの遷移では送信しません。strict-origin-when-cross-origin は同一オリジンではフルURLを送り、外部サイトにはオリジンだけを送るため、解析にも配慮できます。

現在の主要ブラウザのデフォルト挙動に近い点も特徴です。

origin-when-cross-origin：同一オリジンはフルURL、外部はoriginのみ

origin-when-cross-originは、同一オリジン内の遷移では Referer にフルURL（パスやクエリ含む）を送り、外部サイトへの遷移では origin（スキーム+ホスト+ポート）だけを送る設定です。

Referrer-Policy: origin-when-cross-origin

自サイト内の分析精度は保ちつつ、外部へ検索キーワード等が漏れるリスクを減らせます。

unsafe-url：何が危ない？（避けるべき理由）

unsafe-urlは、遷移先が外部サイトでも**参照元（Referer）にフルURL（パスやクエリまで）**を送ります。

Referrer-Policy: unsafe-url

URLに?token=...や?email=...のような情報が入っていると、リンク先や解析ツール、ログに残って漏えいの原因になります。基本は避け、必要ならstrict-origin-when-cross-origin等を選びます。

Referrer-Policyの設定方法まとめ：ヘッダー / meta / 属性

Referrer-Policyを設定する方法は３種類あります。

HTTPヘッダーでの設定例（Nginx / Node / CDNなどの考え方）

HTTPヘッダーでの設定は、サイト全体に一貫したReferrer-Policyを適用できる最も確実な方法です。NginxやNode.js、CDNのレスポンスヘッダーで指定すると、HTMLだけでなく画像やAPI通信にも反映されます。たとえばNginxでは以下のように設定します。

add_header Referrer-Policy "strict-origin-when-cross-origin";

Node.js（Express）でもレスポンスヘッダーとして同様に指定できます。

res.setHeader("Referrer-Policy", "strict-origin-when-cross-origin");

CDNを使う場合も、ヘッダー追加機能で同じ値を設定する考え方になります。

HTMLのmetaでの設定例（ページ全体に効かせる）

<meta name="referrer"> は、そのページ内で発生するリンク遷移・画像/CSS/JS読み込み・フォーム送信などに付く Referer を「ページ全体の既定値」として制御します。

<head>
  <meta name="referrer" content="strict-origin-when-cross-origin">
</head>

HTTPヘッダーより優先度は低いので、本番はヘッダーで統一しつつ、静的ページや一部ページだけ方針を変えたいときに便利です。たとえば外部送信はoriginだけにして、URLパスやクエリ漏えいを抑えます。

referrerpolicy属性とは？（a/iframe/linkなど要素単位での上書き）

referrerpolicy属性は、特定の要素から発生するリクエストだけに Referrer-Policy を適用する仕組みです。サイト全体の方針はヘッダーやmetaで決めつつ、外部リンクや埋め込みだけ挙動を変えたい場合に使います。

<a href="https://example.com" referrerpolicy="no-referrer">外部リンク</a>
<iframe src="https://example.com" referrerpolicy="strict-origin"></iframe>

上の様にa や iframe、linkなどで指定でき、属性の指定はページ全体の設定より優先されます。

Referrer-Policyベストプラクティス：安全性と計測を両立する選び方

ここまで様々な設定値や設定方法を説明しましたが、ではどの設定方法を選べばいいのかと疑問に思う方も多いかと思います。

ここでは、Referrer-Policyを設定する際のベストプラクティスを説明します。

まず考えるべき要件：外部に何を渡したくない？内部は必要？

Referrer-Policyを選ぶ前に、まず「外部サイトに何を渡したくないか」と「自サイト内でどこまで計測したいか」を整理します。

URLのパスやクエリにユーザーID、検索語、管理画面の構造などが含まれる場合、それらを外部に送らない設計が重要です。一方、内部遷移では詳細なURLを使った導線分析が必要なこともあります。

外部には最小限、内部では十分な情報を残すという視点が、現実的なポリシー選択につながります。

推奨されがちな値：strict-origin-when-cross-originが使いやすい理由

strict-origin-when-cross-originは、外部サイトに渡す情報を最小限にしつつ、計測に必要な情報は残すバランス型です。

同一オリジン内の遷移やリクエストでは Referer にページのフルURLが入るため、どのページから来たかの分析がしやすい一方、外部へ出るときは https://example.comのように origin（スキーム+ホスト+ポート）だけに落とします。

さらにHTTPS→HTTPのようなダウングレードでは送信しないため、盗聴リスクも抑えられます。ページURLに付いたクエリ（例：?token= や ?email=）が外部に漏れにくく、実運用で採用しやすい値です。

no-referrerを選ぶべきケース（機密URL・短命リンク・医療/金融など）

no-referrerは、URL自体が機密情報になり得る場面で選ぶべき設定です。

ワンタイムトークン付きの短命リンクや、診療内容・口座操作などがURLに含まれる医療・金融系ページでは、参照元が外部へ渡るだけで情報漏えいにつながります。

外部解析や広告連携よりもプライバシー保護を最優先する設計では、Refererを完全に送らない方針が合理的です。

同一オリジンでの計測（分析）とリファラ制限のトレードオフ

同一オリジンで詳細な計測を行いたい場合、Referer にフルURLが含まれる方が、どのページから遷移したのかを正確に把握できます。

しかし制限を強めすぎると、分析ツールで導線や流入元が見えにくくなります。一方、外部への送信を緩めると、URLに含まれるクエリや内部構造が漏れるリスクが高まります。

このため、内部ではフルURLを許可し、外部では最小限に抑える設定を選ぶことが、計測と安全性の現実的なトレードオフになります。

外部サービス（決済/SSO/問い合わせ）で困るケースと回避策

決済・SSO・問い合わせフォームなど外部サービスに遷移する場面では、Referrer-Policyを厳しくしすぎると「どのページから来たか」を外部側が判定できず、戻り先URLの自動判定・不正検知・導線分析・画面出し分けが崩れることがあります。

回避策は、全体は strict-origin-when-cross-originなどにして情報漏えいを抑えつつ、特定リンクだけreferrerpolicy属性で緩める、外部に渡したい情報はRefererに頼らず state/return_toなど明示パラメータ（改ざん防止の署名付き）で渡す、リダイレクト中継で必要最小限の情報だけを付与する、といった設計に切り替えることです。

まとめ

Referrer-Policyは、リンク遷移や外部リソース取得時に送られるRefererヘッダーの内容を制御し、URLパスやクエリの漏えいを防ぐ仕組み
ディレクティブごとに「送らない」「originのみ」「同一オリジンはフルURL」など挙動が大きく異なる
実運用では strict-origin-when-cross-originが安全性と計測のバランスが良く、最も使われやすい
機密URLや医療・金融系では no-referrerを選ぶ判断も重要
設定はHTTPヘッダーが最優先で、metaやreferrerpolicy属性は補助的に使う
外部サービス連携ではRefererに依存せず、明示的なパラメータ設計が安全

Referrer-Policyは「とりあえず設定する」ものではなく、何を守り、何を計測したいかを考えたうえで選ぶセキュリティ設定です。適切なディレクティブと設定方法を選ぶことで、情報漏えいを防ぎながら実用的なサイト運用が可能になります。

Referrer-Policyの基本：no-referrer等の違いと設定例まとめ

目次