Referrer-Policyの監査方法｜URLの送信範囲を実測し、例外を管理する

外部サイトへのリンクや画像、計測タグを置くページでは、ブラウザが送る Referer ヘッダーにページのパスやクエリが含まれることがあります。会員番号、検索語、案件番号、招待用の識別子などをURLへ含めていると、意図しない宛先へページ情報が伝わるおそれがあります。

監査では、レスポンスヘッダーに Referrer-Policy があるかを見るだけでは足りません。HTMLや要素ごとの指定、CSSからの通信、リダイレクト、JavaScriptがURLを別データとして送る処理を確認し、ブラウザの開発者ツールで実際のリクエストを検証します。2026年9月30日に確認したW3Cの現行Editor’s Draftは、ポリシー未指定時の既定値を strict-origin-when-cross-origin と説明していますが、ユーザーエージェントがさらに情報を減らす場合もあります。既定値を知ることと、自社ページの送信内容を確かめることは別の作業です。

手順の要点は、同一オリジン・HTTPSのクロスオリジン・HTTPSからHTTPへの通信を合成データで再現し、期待する値と実際の Referer を比べることです。

---

本記事のポイント

1. strict-origin-when-cross-originでは、同一オリジンにパスとクエリを含むURL、HTTPSの別オリジンにはoriginだけが送られます。
2. オリジンはスキーム・ホスト・ポートの組み合わせです。サブドメイン、ポート、HTTPとHTTPSの違いも監査ケースに含めます。
3. 例外は対象通信・理由・担当者・期限・再確認日を記録し、実際のリクエストで必要な範囲だけ残します。

---

Referrer-Policyで制御するのはRefererヘッダーに含めるURL情報

Referrer-Policy は、ページから送るリクエストや遷移で、Referer ヘッダーにどの範囲の参照元URLを含めるかを決める仕組みです。ヘッダー名の Referer は綴りが異なりますが、設定名は Referrer-Policy です。ポリシーを読む前に、比較対象の「同一オリジン」を揃えます。オリジンはスキーム・ホスト・ポートで決まり、パスやクエリは含みません。したがって、同じホスト上の別パスは同一オリジンでも、https://portal.example.test と https://img.portal.example.test はホストが違うため別オリジンです。有効なポート番号が異なる場合や、HTTPとHTTPSの違いも別オリジンとして扱います。HTTPSの既定ポート443を明記したURLと、省略した同じホストのURLは同一オリジンです。

代表的なポリシーで送られる参照元情報

ポリシー	同一オリジン	別オリジンのHTTPS	HTTPSからHTTP
strict-origin-when-cross-origin	パス・クエリを含むURL（フラグメント等を除く）	originだけ	ヘッダーを送らない
no-referrer	送らない	送らない	送らない
same-origin	パス・クエリを含むURL	送らない	送らない
strict-origin	originだけ	originだけ	送らない
unsafe-url	パス・クエリを含むURL	パス・クエリを含むURL	パス・クエリを含むURL

表はHTTPSの参照元から通常のWeb宛先へ送る場合の基本的な期待値です。localhostなど仕様上の「信頼できる可能性があるURL」の例外、ブラウザ独自の削減、個別要素の別指定は含みません。検証先と適用された設定を記録して比較してください。

この表の「originだけ」は、たとえば https://portal.example.test/ の形です。現在の仕様モデルでは、URLをRefererとして送る前にユーザー名・パスワードとフラグメント（#以降）が取り除かれます。originだけに縮める場合は、さらにパスとクエリも外れます。ただし、同一オリジンへの通信では strict-origin-when-cross-origin でもパスとクエリが残ります。社内APIや同一サイトの計測先だけをテストして「外部へも安全」と判断しないでください。

origin や origin-when-cross-origin は、HTTPSページからHTTP宛てでもoriginを送る構成になり得ます。HTTPSからより安全性の低い宛先へ参照元を出さない要件では、strict-origin 系の挙動を選択肢に含めます。一方、unsafe-url はパスとクエリを送る範囲が広く、機密値をURLに置いたまま使う理由にはなりません。どの値が最適かは、サイト運用に必要な計測情報、宛先、URLに含まれるデータを分けて判断します。

監査は設定値の一覧ではなく適用経路で見る

Referrer Policyは、HTTPレスポンスヘッダーのほか、HTMLの <meta name="referrer">、リンクや画像などの要素に付ける referrerpolicy 属性で指定できます。リンクの rel="noreferrer" のように個別の送信で参照元を抑える仕組みもあります。CSSのレスポンスやスタイルシートから発生する取得も対象になり得るため、HTML文書の先頭だけ見て終わりにせず、実際にリクエストを起こす資産と要素を洗い出します。

異なる指定元がある場合に「常にこの設定が優先」と一律に決めつけず、ページのレスポンス、DOM上の指定、通信を起こした要素、ブラウザが送信したヘッダーを一つの記録で結びます。複数のポリシー値、空値、未知の値、ページ遷移後の状態も確認対象です。ポリシーが設定されていることと、すべての通信で意図した結果が得られることは同じではありません。

ページテンプレート別に結果を整理すると、共通ヘッダーの修正だけで直る範囲と、特定の埋め込みや計測タグに限定した調整を分けられます。たとえばCSPは通信先を制限する仕組みで、Refererのパスやクエリを削るものではありません。ヘッダーごとの役割を切り分けたうえで、CSP Report-Onlyの違反を観測して本番制限へ移す手順と同じように、対象ページと例外を段階的に確認します。

6段階で対象ページと実際の通信を照合する

1. 対象範囲を決める。公開ページ、ログイン後画面、フォーム完了画面、LP、埋め込みや外部タグのあるページを一覧にします。各URLに顧客IDや検索語を含む可能性があるか、外部へ送るリクエストの種類は何かも記録します。対象を「トップページ」だけに絞ると、経路ごとの設定差を見逃します。
2. 合成データでテストを用意する。管理下の検証環境に、たとえば https://portal.example.test/customer/view?case=DEMO-001#overview のような実在しない値を使います。同じホストの別パス、別ホストのHTTPS、サブドメイン、管理下でリクエストを受けられるHTTP宛先を用意します。実ユーザーのURL、顧客ID、セッション値、アクセストークンは使いません。
3. ページが受け取った指定を記録する。ブラウザのNetworkパネルで、最終表示ページのレスポンスヘッダーを確認します。HTMLのmeta、リンク・画像・iframe等の属性、CSSや埋め込みページ、サーバー側のテンプレートも調べます。初回応答だけでなくリダイレクト後のページや、キャッシュされた応答かどうかも記録します。
4. 宛先別に通信を発生させる。合成URLから同一オリジン、別オリジンのHTTPS、サブドメイン、HTTPSからHTTPの順にテストします。それぞれで送信先、リクエスト種別、Referer の有無と値を比較します。HTTPSからHTTPへの要求がブラウザに遮断された場合は、観測できるリクエスト自体がありません。その結果を「ポリシーによりヘッダーが省略された」とは判定しません。
5. リダイレクトと別送信を追う。Networkパネルで各通信と転送先を確認し、最初に押したリンクのHTMLだけで結論を出しません。OAuthのコールバックや認証後の戻り先を含む画面では、OAuthリダイレクトURIの棚卸しと変更記録も参考に、どのページからどの宛先へ進んだかを追跡します。JavaScriptが location.href の一部を計測URLやリクエスト本文に明示して送る処理は、Refererヘッダーの制御だけでは防げません。
6. 期待値・実測・対応を一行で残す。ページ、ブラウザとバージョン、指定元、送信先、期待する値、実測値、判定、修正担当、再確認日を記録します。実際の受信側でヘッダーを確認できる場合は、開発者ツールの表示と突き合わせます。HARを共有するときは、Cookie、認証ヘッダー、実URLのクエリ、顧客識別子を除去します。

図のとおり、設定値は監査の入口です。合成URLのテストでも、通信が発生しなかったケースは「ヘッダーを送らなかった」とは別に記録します。混在コンテンツ制御、CSP、拡張機能、キャッシュなどにより通信が見えない可能性があり、実測できない項目は合格ではなく「判定できず」として再試験条件を残します。設定値と実際の送信内容を照合して初めて、リファラの監査は完了します。

例外は必要な通信だけに絞って期限を付ける

広告計測、外部フォーム、埋め込みなどで参照元が必要だと分かった場合は、ページ全体を緩める前に、受信側が必要とする情報を確認します。originだけで目的を満たせるか、URLのパス・クエリまで必要なのか、Referer以外の合成イベントで代替できるのかを相手先の仕様と自社のプライバシー要件に照らします。必要な場合も、対象となる要素や通信に範囲を限定し、他のリンクや資産へ設定が広がっていないか実測します。

例外台帳には、対象ページと要素、送信先、設定値、業務上の目的、送信される情報の範囲、承認者、実装担当、開始日、期限、再確認日、テスト証拠を記録します。「計測に必要」とだけ書かず、どの指標にどの情報が必要かを明らかにします。目的が終了した例外は削除し、第三者タグの更新や遷移先の変更があれば再確認します。

OAuthの認証遷移や外部サービスへのコールバックは、別ページの戻り先URLやリダイレクト途中の送信があるため、初期ページのヘッダーだけで扱いを決めないことが重要です。また、Referrer Policyを厳しくしても、リンク先URLそのもの、リクエスト本文、ログ、画面上のコピーなど別経路で値が渡る場合があります。秘密情報や長期間有効な識別子をURLへ含めない設計を優先し、ポリシーは残る情報を減らす補助策として使います。

監査記録をページ更新とリリース後の確認につなぐ

判定記録は「URL漏えいなし」の一文で閉じず、どの条件で確認したかを再現できる形にします。記録例は、ページ群、合成URL、遷移先、応答ヘッダー、HTML/CSS上の指定、ブラウザ、期待値、実測値、遮断の有無、例外ID、担当、期限です。修正後は同じテストを再実行し、関連ページやタグの更新で結果が変わっていないかを確認します。未検証のブラウザや埋め込みは対象外と明記します。

ページのオーナー、外部資産、計測目的、変更承認者を管理すると、担当者が変わった後も例外の必要性を見直せます。更新や廃止の責任、承認、レビュー日をサイト単位で揃える方法は、Webサイトのコンテンツガバナンスも参照してください。フォームや計測イベントの要件も、ページ公開前に必要な項目と送信先を決めておきます。

優先順位は、外部へ送られる値が実在の顧客情報か、URLがアクセス権限の代わりになるか、送信先が管理外か、対象ページがどれだけ広いかで決めます。実際の秘密値や個人データが送られていた場合は、ポリシー修正だけで済ませず、値の失効・変更、ログの保管範囲、関係者への連絡要否を社内手順に沿って判断します。対象・証拠・期限が揃わない例外は、期限付きの保留として扱い、公開範囲を広げる前に再試験します。

よくある質問

strict-origin-when-cross-originなら、URLのパスやクエリは外部へ送られませんか？

HTTPSの別オリジンへの通信では、Refererはoriginだけに縮小され、パスとクエリは含まれません。ただし同一オリジンへのリクエストには、フラグメントなどを除いたパスとクエリが含まれ得ます。別オリジンかどうかはスキーム・ホスト・ポートで確認してください。

同じ会社ドメインのサブドメインは同一オリジンですか？

いいえ。www.example.test と forms.example.test はホストが異なるため別オリジンです。会社が管理しているか、同じ親ドメインかどうかではなく、スキーム・ホスト・ポートの組み合わせで比較します。

Refererヘッダーが見えなければ監査は合格ですか？

それだけでは判断できません。HTTP宛て要求が混在コンテンツとして遮断された、CSPや接続障害で通信自体がなかった、開発者ツールに必要な記録が残っていない可能性があります。テスト要求が発生したことと、受信側でのヘッダー値を確認できたことを分けて記録します。

JavaScriptでページURLを送る場合もReferrer-Policyで抑制できますか？

アプリのコードがページURLやその一部を計測イベントのパラメータ、リクエストURL、本文へ明示的に入れる送信は、Refererヘッダーのポリシーでは除去されません。ソースコードと実際の送信本文を確認し、不要な項目を送らない設計にします。

HTTPヘッダーだけ設定すれば、metaや要素属性の確認は不要ですか？

不要とは言えません。HTMLのmeta、個別要素の属性、CSSや埋め込み、リダイレクトなど別の指定・通信経路が関係する場合があります。どの指定が存在するかを調べたうえで、対象ブラウザのリクエストで結果を照合してください。

Referrer-Policyの設定や外部通信の点検を含め、BtoBサイトの訴求・フォーム・計測を一緒に見直したい場合は、ファネルAiへLP・Web改善を相談することができます。ページごとの設定と実際の送信内容を確認し、読者に必要な情報を保った改善順を整理します。