Referrer-Policyとは？8つの値の違い・推奨値・診断基準・設定方法

Referrer-Policy（リファラーポリシー）とは

Referrer-Policyとは、ブラウザが送る Referer リクエストヘッダーの内容をサイト側から制御するレスポンスヘッダーです。ブラウザはリンクのクリックや画像・スクリプトの読み込み時に、遷移元ページのURLを Referer として送ります。Referrer-Policy は、その送信内容を「完全なURL」「オリジンのみ」「送らない」のどれにするかを決めます。

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

URLのパスやクエリ文字列には、検索語、受付番号、メールで送られた一時的なリンクのトークン、職員用画面のパスなどが入ることがあります。自治体サイトは外部の地図サービス、動画サイト、SNS、アクセス解析、電子申請システムなど多くの第三者へリンク・読み込みを行うため、どこまでの情報を外へ出すかを明示的に決めておくことが重要です。

Referrer-Policyの値と送信内容の違い

8つのポリシー値

W3C Referrer Policy で定義されている値と、Referer に入る内容は次のとおりです。

上の4つ（no-referrer、same-origin、strict-origin、strict-origin-when-cross-origin）は、クロスオリジンへ完全URLを送らず、HTTPへのダウングレード時にも情報を出さない値です。MDN HTTP Observatory もこの4値を「private」、残りの4値を「unsafe」に分類しています。

複数値とmeta要素の扱い

• ヘッダーの複数値：仕様では、カンマ区切りの各トークンのうち認識できる最後の値が採用され、未知の値は無視されます。古いブラウザ向けのフォールバックとして Referrer-Policy: no-referrer, strict-origin-when-cross-origin のように書けます。
• meta 要素：HTML Standard では <meta name="referrer" content="..."> が挿入されると、文書のリファラーポリシーをその値で上書きします。旧来の値 never→no-referrer、always→unsafe-url、default→既定ポリシー、origin-when-crossorigin→origin-when-cross-origin に読み替えられます。meta は1つの値だけを受け付けます。
• 要素単位の指定：<a referrerpolicy="..."> や rel="noreferrer" で個別に変更できます。

ブラウザ既定値とReferrer-Policyについてよくある誤解

• 「ヘッダーがない＝完全URLが外部へ漏れる」：仕様と MDN によれば、ポリシーが指定されていない場合の既定値は strict-origin-when-cross-origin です（MDN によれば 2020年11月の仕様改訂でこの値になり、それ以前は no-referrer-when-downgrade でした）。そのため未設定でも完全URLが外部へ漏れるとは限りません。ただし、web.dev は「ブラウザによって既定ポリシーが異なる」ため明示的に設定することを勧めています。ASVS V3.4.5 も「ポリシーを設定していること」を要件にしています。
• 「Referer をCSRF対策に使う」：web.dev は Referer を CSRF 対策に使わず、CSRF トークンを使うよう勧めています。リファラーポリシーを厳しくすると、Referer チェックに依存した仕組みが動かなくなることがあります。
• 「no-referrer が最も良い」：漏えい防止としては最も強いですが、アクセス解析で参照元サイトが分からなくなる、Referer を確認する外部サービス（地図API キーの HTTP リファラー制限など）が動かなくなる、といった影響があります。一般的な公開サイトでは strict-origin-when-cross-origin が均衡の取れた選択です。

Referrer-Policyの診断基準（セキュリティAIチェッカー）

取得方法

• 入力URLへ GET を1回送信し、リダイレクトを最大4回追跡した最終応答の Referrer-Policy ヘッダーと、取得した HTML（最大2MB）中の <meta name="referrer"> を評価します。追加の通信は行いません。
• ヘッダー値はカンマで分割し、仕様で定義された8値のうち最後に現れた認識可能な値を有効値とします。
• meta 要素（HTML 中で最初に現れる1つ）に認識可能な値（旧来の4値の読み替えを含む）がある場合は、ブラウザと同様に meta の値を有効値とします。認識できない値の場合はヘッダーの有効値を使います。対象は name="referrer" と content="…" を引用符付きで書いた meta で、属性値に < や > を含むタグは検出しません。

判定条件

• 根拠欄には、ヘッダー値・meta の値と、採用された有効値を表示します。
• × を使わないのは、未設定でも主要ブラウザが安全側の既定値で動作するため、また緩い値であっても直ちに重大な脆弱性とは言えず、URLにどのような情報を載せているかの確認が必要だからです。

自治体サイトでの判定例

Referrer-Policyが不適切だとどんなリスクがあるか

漏えい・攻撃のシナリオ

1. URLに含まれるトークンの漏えい：パスワード再設定、申請状況確認、ファイル共有などで、URLに一時的なトークンや受付番号を含む設計がある。そのページから外部の画像・スクリプト・リンク先へアクセスすると、完全URLが Referer として第三者のサーバーログに残ります。web.dev は、こうした「capability URL」が意図しない相手に渡ると乗っ取りにつながる危険を指摘しています。
2. 検索語・閲覧内容の第三者送信：サイト内検索の語句（相談内容、病名、福祉制度名など）がクエリ文字列に入り、外部のアクセス解析や埋め込みコンテンツの配信元へ送られる。住民のプライバシーに関わる情報が意図せず外部へ出ることになります。
3. 内部構成の露出：職員向けや非公開のページのパス・ホスト名が、外部リンク経由で第三者に知られる。ASVS V3.4.5 は、内部の非公開アプリケーションではホスト名自体も機微情報になり得ると述べています。
4. HTTP へのダウングレード時の平文送信：unsafe-url や origin を指定すると、HTTPS ページから HTTP の外部サイトへ移動した際に、URL やオリジンが暗号化されずに送られます。

想定される被害

• 住民の個人に関わる閲覧・検索情報の第三者への提供（個人情報保護の観点での問題）
• 一時リンクを使った手続き画面への不正アクセス
• 攻撃者による内部システム構成の把握

Referrer-Policyの設定方法（Apache・nginx・IIS・Next.js・meta要素）

推奨値

一般的な自治体公式サイトでは、次の設定を推奨します。

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

職員用システムや、URLに識別子を含む手続き画面など、外部へ参照元を一切出したくない領域では no-referrer または same-origin を個別に設定します。

Apache（.htaccess / httpd.conf）

<IfModule mod_headers.c>
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

特定ディレクトリ（例：申請状況確認ページ）だけ厳しくする場合は、そのディレクトリの .htaccess で Header always set Referrer-Policy "no-referrer" と上書きします。

nginx

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

location /apply/status/ {
    add_header Referrer-Policy "no-referrer" always;
    # この location に add_header を書いたため、server 側の add_header（X-Content-Type-Options など）は
    # この location には継承されない。必要なヘッダーはここにも書くこと（nginx 1.29.3 以降は add_header_inherit merge; でも可）
}

IIS（web.config）

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="Referrer-Policy" value="strict-origin-when-cross-origin" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

Next.js（Vercel）

// next.config.js
module.exports = {
  async headers() {
    return [{
      source: "/:path*",
      headers: [{ key: "Referrer-Policy", value: "strict-origin-when-cross-origin" }],
    }];
  },
};

サーバー設定を変更できない場合（CMS テンプレートのmeta要素）

共通ヘッダーテンプレートの <head> 内、できるだけ前方に次を追加します。

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

meta は、それより前に読み込まれたリソースには適用されない場合があるため、<head> の先頭付近に置きます。

サイトを壊さないための注意点

• 外部APIのリファラー制限：地図や検索などの外部APIキーに「HTTPリファラー制限」をかけている場合、no-referrer にすると Referer が送られずに認証エラーになります。strict-origin-when-cross-origin ならオリジンは送られるため、多くの場合はオリジン単位の制限で動作します。設定変更後に地図・埋め込み動画・外部フォームの動作を確認してください。
• アクセス解析：no-referrer / same-origin では、遷移先サイトで本サイトからの流入が計測されなくなります。
• Referer に依存する独自チェック：古いCMSやフォームで Referer による送信元確認を行っている場合、同一オリジン内では strict-origin-when-cross-origin でも完全URLが送られるため通常は影響しませんが、no-referrer では失敗します。

設定後の確認方法

curl -sI https://www.example.lg.jp/ | grep -i referrer-policy
curl -s https://www.example.lg.jp/ | grep -i -o '<meta[^>]*name="referrer"[^>]*>'

ブラウザの開発者ツールで、外部リソースへのリクエストの Referer がオリジンのみ（例：https://www.example.lg.jp/）になっていることも確認します。設定後はセキュリティAIチェッカーで再診断し、根拠欄の「有効値」が推奨値になっていることを確かめてください。

よくある質問（FAQ）

参考資料

• W3C Referrer Policy（Editor's Draft）
• HTML Standard（meta name="referrer" の処理）
• MDN: Referrer-Policy
• web.dev: Referer and Referrer-Policy best practices
• OWASP ASVS 5.0.0 V3 Web Frontend Security
• OWASP WSTG-CONF-14
• MDN HTTP Observatory の Referrer Policy テスト実装
• OWASP Secure Headers Project

「Referrer-Policy」と関連する診断項目

• 別タブリンクのnoopenermedium
• 外部iframeのsandboxmedium
• Refererをアクセス制御に使っていないcritical
• 機密情報をURL・GETフォームへ含めないcritical
• クリックジャッキング対策high
• MIMEスニッフィング対策medium
• Permissions-Policylow
• Cross-Origin-Opener-Policylow