目次
パスワード再設定や招待のURLを開いた後、外部サイトへ移動すると、そのURLの一部が参照元として送信される場合があります。Webアプリの開発・運用担当者は、Referrer-Policyを設定し、送信先へ渡す情報を必要な範囲へ絞れます。ただし、同一オリジンへの送信やページ内の別設定も確認しなければ、ヘッダーを一行追加しただけでは点検が完了しません。
本記事は2026年10月27日に公式資料を確認した恒久対策の実践解説です。特定のや侵害の速報ではありません。URLに含まれる識別子やの漏えいを防ぐ目的で、ポリシーの選択、配信設定、ブラウザーでの検証を扱います。例のと値は仮想で、検証手順は本サイトの提案です。
スポンサーリンク
Refererは移動先だけでなくリソース取得にも付く
Refererはリクエストのヘッダー名で、参照元の情報を受信側へ伝えます。制御する応答ヘッダーの名前はReferrer-Policyです。両者では綴りが異なります。外部リンクのクリックだけでなく、画像などのリソース取得も点検対象です。まず、どのページからどの宛先へリクエストが出るかを確認します。
仮に、再設定画面のURLがhttps://app.example/reset?token=TESTであるとします。受信側へ完全な参照元が送られれば、パスとクエリーから用途や値を知ることができます。TESTは試験用文字列であり、本物のトークンを使って調査してはいけません。相手が攻撃者でなくても、受信ログへ不要な情報が残ることが問題になります。
W3CのReferrer Policy編集者草案（策定中の文書）は、ページのURLが持つ情報の漏えいをセキュリティ上の論点として扱っています。一方、参照元は流入分析や不正利用の調査にも使われます。そのため、全画面で何となく同じ値にするのではなく、外部へ渡してよい情報と、受信側が必要とする情報を先に決める必要があります。
最初に同一オリジンと外部宛てを分ける
オリジンはスキーム、ホスト、ポートの組み合わせです。見た目が同じサービスでも、app.exampleとassets.exampleは異なるオリジンになります。ドメインの末尾が共通だから同一オリジンだと判定せず、実際のURLで整理します。内部の資産と外部委託の資産を分ける作業とは、また別の分類になります。
MDNが説明するstrict-origin-when-cross-originでは、同一オリジンへはパスとクエリーを含む参照元を送り、から別のHTTPSオリジンへはオリジンだけを送ります。HTTPSからHTTPへの送信では参照元を送りません。現在の既定値として説明されていますが、サイト側の指定やブラウザー設定を確認せず、必ずその挙動になると仮定しないでください。
つまり、外部へのクエリー漏えいを抑えられても、同一オリジンの画像配信やログには情報が届く可能性があります。秘密を含むページでは、同一オリジンのアクセスログも対象にして確認します。分析用の値と認証に使える値では、漏れた場合の影響が違うため、URLのパラメーター名だけでなく用途まで台帳へ記録します。
スポンサーリンク
候補となる三つのポリシー
通常の公開ページで、外部へはサイトのオリジンだけを伝えたい場合はstrict-origin-when-cross-originが候補です。同一オリジン内の詳細な参照元は維持されます。これが必要な業務なのか、それとも単に昔から残っている計測なのかを、分析や運用の担当者と確認して選択します。
same-originは、同一オリジンへは詳細な参照元を送り、別のオリジンへは送りません。外部のサービスにサイトの出所も渡したくない場合に検討できますが、同一オリジンのログへ秘密を残す問題は解消しません。サブドメインを含む構成で使う際も、オリジンの違いを確認する必要があります。
no-referrerは参照元を送らない方針です。再設定、招待、機微な情報を扱う画面では有力な候補になります。ただし、参照元に依存する機能の確認は必要です。unsafe-urlは安全な宛先かどうかにかかわらずパスとクエリーを送り得るため、計測を復活させる目的で安易に選ばないようにします。
応答ヘッダーとHTMLの指定を整理する
HTTP応答で指定する最小例は次のとおりです。これは送信する参照元を抑える設定例であり、アプリへの認証やを追加するものではありません。どの配信層で値を管理するかを決め、アプリ、Webサーバー、が別々の方針を付けないようにします。
Referrer-Policy: no-referrerHTMLで文書全体へ指定する場合は、meta要素を使う方法もあります。リンクや画像などではreferrerpolicy属性により個別のリクエストへ指定できます。既存テンプレートに古い値が残っていると、応答ヘッダーを直したつもりでも、要素単位の通信を見落とす原因になります。最終的なと実際の通信を両方確認します。
<meta name="referrer" content="no-referrer">
<a href="https://partner.example/" referrerpolicy="no-referrer">外部サービス</a>外部リンクのrel="noreferrer"も参照元を送らない指定です。noreferrerと、文書ポリシーのno-referrerは書式が違います。また、別の目的で使うnoopenerだけを付けても、参照元を非送信にしたことにはなりません。テンプレートの一括置換では、属性名と値をそれぞれ確認し、目的に合わない指定へ機械的に置き換えないことが大切です。
外部CSSから読み込まれるリソースには、そのCSSの応答に付くReferrer-Policyなどが関係します。HTML文書だけ見て、スタイルシート経由の通信まで確認済みにしないでください。画像の背景指定やフォント配信など、自社ページが発生させる取得先を開発者ツールでたどり、別の参照元が使われる経路を切り分けます。
スポンサーリンク
機微な画面から小さな範囲で導入する
導入前には、再設定、招待、管理画面、検索結果など、URLに情報が載りやすい画面を一覧にします。各画面について、外部リンク、画像、CSS、iframe、フォームの送信先を調べます。すべてを危険と決めつけるのではなく、どの値がどこへ渡ると困るかを具体的にする作業です。
次に、既存の応答ヘッダー、meta、要素のreferrerpolicy、noreferrerを確認します。通常ページと特別な画面で方針を変えるなら、その理由と責任者を記録します。CDNのから古い応答が返る場合もあるため、設定画面の変更だけで反映済みにせず、利用者が受け取る公開側の応答で確認します。
変更の順序としては、検証環境で影響を確認し、機微な情報が載る限定した画面から適用する方法が考えられます。流入分析や連携機能の担当者へ、減る情報の範囲を伝えます。計測が変わった場合は、秘密を含むURLを再送する設定へ戻す前に、専用の安全なイベント情報など別の設計で要件を満たせないか検討します。
開発者ツールで送信される値を確認する
検証では自分で管理する二つのオリジンを用意し、送信元ページのURLに機密ではない目印を入れます。Networkパネルを開いてログを保持し、リンク移動やリソース取得を実行します。送信先へのリクエストを選び、Request HeadersのRefererを確認します。送信元のResponse Headersにポリシーが見えることと、送信結果が期待どおりであることは別の確認です。
試験は少なくとも、同一オリジンへのリンク、別HTTPSオリジンへのリンク、画像取得、個別属性を持つリンクに分けます。no-referrerなら対象の参照元が送信されないこと、strict-origin-when-cross-originなら同一オリジンと外部で情報量が変わることを確かめます。HTTPへの遷移試験が必要な場合も、実データを使わず管理下の環境で行います。
ブラウザーがヘッダーを暫定表示していたり、キャッシュや拡張機能が影響したりすると、画面だけでは判定しにくい場合があります。管理する受信側のログと突き合わせ、対象ブラウザー、試験時刻、送信元、宛先、期待値、観測値を記録します。HARを保存する場合はやが含まれ得るため、共有前に内容を確認します。
curlで応答ヘッダーを見る作業は配信設定の確認には使えますが、ブラウザーが参照元をどう生成するかの検証にはなりません。curlで自分が指定したRefererが届いたことを、ブラウザーのポリシー適用の証拠にしないようにします。自動試験へ移す場合も、単なるヘッダー文字列の検査と実際のブラウザー通信を分けて設計します。
フォームと認証の回帰も忘れない
Referrer-PolicyはRefererだけを見て終える設定ではありません。MDNは、一部のフォーム送信などではOriginがnullになる場合も説明しています。一方、corsモードのfetchなどは扱いが異なります。認証や対策がこれらのヘッダーを利用する場合、実際の送信方法ごとに正常系と拒否する系を試験します。
参照元が消えたためにフォームが拒否されても、対策としてCSRF検証を無効にしたり、nullをすべて信頼したりしてはいけません。現在の実装が何を判定しているかを確認し、アプリの保護方針に沿って修正します。参照元ポリシーはアクセス権限を与える仕組みではなく、送信する情報を減らす仕組みとして扱います。
URLから秘密を減らす設計と組み合わせる
このヘッダーは、URLそのものを秘密の保管場所に変える機能ではありません。アドレスバー、履歴、サーバーログ、画面のコピーや分析スクリプトなど、参照元以外にも情報が残る経路があります。機微な値をURLへ載せる必要があるかを見直し、必要な場合も期限や用途を制限し、値の再利用を抑える設計と組み合わせます。
すでに値が外部へ送られた疑いがあるときは、ポリシーの変更だけで過去の漏えいが解消したとは判断できません。対象のURL、期間、送信先、値の権限と有効期間を調べ、必要に応じて失効やログ保管先への対応を検討します。調査のために同じ秘密値を別の外部解析サービスへ送ることも避けてください。
完了の目安は、方針を選び、公開側の応答と要素の指定を確認し、代表経路の送信値とフォームの動作を確かめられた状態です。サイトの配信基盤や外部タグを変更した際には同じ試験を再実行します。単にヘッダーが存在するかではなく、渡してよい情報だけが必要な相手へ届くかを継続して確認することが、URL情報の漏えい防止につながります。
スポンサーリンク
関連記事
HTTPSを継続して使わせる通信保護については、HSTSを段階導入する前の確認事項も参照してください。参照元の情報量を制御する本記事とは異なる対策です。
参考資料
MDN：Referrer-Policy header
W3C：Referrer Policy編集者草案（策定中の文書。確定標準として扱っていません）
