Referrer-Policy のおすすめ設定値｜Web 担当者向け解説
目次
この記事でわかること
- Referrer-Policy が「Referer ヘッダで何を送るか」を制御する仕組み
- 8 つの設定値の比較とプライバシー保護の強さ
- Web サイトで推奨される値
- Referrer-Policy 未設定で起きうる情報漏洩の典型例
Referrer-Policy は「Referer で何を送るか」を制御する
ブラウザは外部サイトにリクエストする時、自動的に Referer ヘッダを付けて「どこから来たか」を相手サーバーに伝えます。これは Web のリンク追跡やアクセス解析の基本機能で、悪いものではありません。
ただし Referer に クエリパラメータの機密情報が含まれていると、外部サイトに知られたくない情報が漏れます。
GET /partner-resource HTTP/1.1
Host: external-tool.example.com
Referer: https://app.example.co.jp/customer/[email protected]&auth_token=secret
Referrer-Policy はこの送信を制御するヘッダです。
Referrer-Policy: strict-origin-when-cross-origin
情報漏洩の典型例
よく起きるな例:
- 社内 SaaS 管理画面: 顧客メール / 案件 ID 等が URL に含まれる状態で、画面内の外部リンク（資料 PDF など）を踏むと相手のアクセスログに残る
- ECサイトの注文確認画面: 注文番号 / 商品 ID 等が外部の決済代行 / 配送会社の解析ツールに渡る
- 管理者向けダッシュボード: クエリで token を渡している場合、外部画像読み込み時に漏れる
URL にクエリで機密情報を含めない設計が理想ですが、現実には残っています。Referrer-Policy で「外部にはオリジンだけ送る」設定にすれば、URL のパスやクエリは漏れません。
8 つの設定値の比較
主要な値を整理します。
| 値 | 同一オリジン | 別オリジン HTTPS | HTTP 降格時 |
|---|---|---|---|
no-referrer |
送らない | 送らない | 送らない |
strict-origin-when-cross-origin（推奨） |
フル URL | オリジンのみ | 送らない |
same-origin |
フル URL | 送らない | 送らない |
strict-origin |
オリジンのみ | オリジンのみ | 送らない |
origin-when-cross-origin |
フル URL | オリジンのみ | オリジンのみ（HTTPS→HTTP も送る） |
origin |
オリジンのみ | オリジンのみ | オリジンのみ |
no-referrer-when-downgrade（非推奨） |
フル URL | フル URL | 送らない |
unsafe-url（非推奨） |
フル URL | フル URL | フル URL |
重要な用語
- オリジン: スキーム + ドメイン + ポート（例:
https://example.co.jp） - フル URL: オリジン + パス + クエリ（例:
https://example.co.jp/customer/123?token=x） - HTTP 降格: HTTPS から HTTP へのリクエスト（盗聴リスクがある）
推奨値: strict-origin-when-cross-origin
Referrer-Policy: strict-origin-when-cross-origin
これは モダンブラウザ（Chrome / Firefox / Safari の現行版）のデフォルトでもあります。
- 同一オリジン内のリンクには フル URL を送る（自社内アクセス解析は機能する）
- 別オリジン HTTPS には オリジンのみ を送る（外部に URL のパスや token が漏れない）
- HTTP 降格時は 送らない（盗聴リスクのある経路には情報を渡さない）
ブラウザのデフォルトと同じだから書かなくても良い、と思われがちですが、明示しておくのが安全です。理由:
- 古いブラウザは違うデフォルトを持つ
- Referrer-Policy ヘッダがあれば、ブラウザのデフォルト変更にも影響を受けにくい
- セキュリティチェックツールで「設定済み」として検出される
より厳しくしたい場合: same-origin / no-referrer
機密情報を扱う管理画面・社内システムでは、外部リンクを踏んでも一切 Referer を送らない設定が安全:
Referrer-Policy: no-referrer
または同一オリジン内だけ Referer を送る:
Referrer-Policy: same-origin
ただしこの場合、外部の SaaS にユーザーを誘導する時のアクセス解析（自社からの流入として認識されない等）に影響が出ます。トレードオフを理解した上で選択。
サーバー別の設定例
Cloudflare（Transform Rules）
ダッシュボード → Rules → Transform Rules → Modify Response Header
- Header name:
Referrer-Policy - Value:
strict-origin-when-cross-origin
Nginx
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
WordPress（.htaccess）
Header always set Referrer-Policy "strict-origin-when-cross-origin"
meta タグでも設定可能
HTML の <head> に書いても効きます:
<meta name="referrer" content="strict-origin-when-cross-origin">
ただし HTTP ヘッダで設定するのが標準的で、エラーページ等にも一貫適用されるため安全です。
まとめ
- Referrer-Policy は Referer ヘッダで送る情報量を制御する
- 推奨:
strict-origin-when-cross-origin（モダンブラウザのデフォルトと同じ、明示する） - 機密情報を扱う管理画面では
same-originやno-referrerも検討 - 設定はサーバー側ヘッダで（meta タグより一貫適用される）
まずは現状を把握しましょう
自社サイトに Referrer-Policy が設定されているかは、ドメイン番人の Web セキュリティヘッダ 単発チェック で 30 秒で確認できます。
設定支援が必要な場合は Web セキュリティヘッダ診断＋設定支援（3 万円〜）でご相談ください。CSP の入門は CSP（Content-Security-Policy）とは？Web 担当者のための入門、HSTS は HSTS の設定方法、クリックジャッキング対策は X-Frame-Options と CSP frame-ancestors を、カメラ / マイク / 位置情報など機能を制限する permissions-policy ヘッダー も合わせて検討してください。
総合点検は 無料のドメイン診断、SSL 単独は SSL 単発チェック をご利用ください。