## この記事でわかること - 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/12345?email=tanaka@target.co.jp&auth_token=secret ``` Referrer-Policy はこの送信を制御するヘッダです。 ``` Referrer-Policy: strict-origin-when-cross-origin ``` ## 情報漏洩の典型例 ![Referer 漏洩の典型シナリオ](/blog/referrer-policy-osusume/leak-scenario.svg) よく起きるな例: - **社内 SaaS 管理画面**: 顧客メール / 案件 ID 等が URL に含まれる状態で、画面内の外部リンク（資料 PDF など）を踏むと相手のアクセスログに残る - **ECサイトの注文確認画面**: 注文番号 / 商品 ID 等が外部の決済代行 / 配送会社の解析ツールに渡る - **管理者向けダッシュボード**: クエリで token を渡している場合、外部画像読み込み時に漏れる URL にクエリで機密情報を含めない設計が理想ですが、現実には残っています。Referrer-Policy で「外部にはオリジンだけ送る」設定にすれば、URL のパスやクエリは漏れません。 ## 8 つの設定値の比較 ![Referrer-Policy 値の比較](/blog/referrer-policy-osusume/policy-comparison.svg) 主要な値を整理します。 | 値 | 同一オリジン | 別オリジン 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 降格時は **送らない**（盗聴リスクのある経路には情報を渡さない） ブラウザのデフォルトと同じだから書かなくても良い、と思われがちですが、**明示しておくのが安全**です。理由: 1. 古いブラウザは違うデフォルトを持つ 2. Referrer-Policy ヘッダがあれば、ブラウザのデフォルト変更にも影響を受けにくい 3. セキュリティチェックツールで「設定済み」として検出される ## より厳しくしたい場合: `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 ```nginx add_header Referrer-Policy "strict-origin-when-cross-origin" always; ``` ### WordPress（.htaccess） ```apache Header always set Referrer-Policy "strict-origin-when-cross-origin" ``` ## meta タグでも設定可能 HTML の `` に書いても効きます: ```html ``` ただし HTTP ヘッダで設定するのが標準的で、エラーページ等にも一貫適用されるため安全です。 ## まとめ - Referrer-Policy は Referer ヘッダで送る情報量を制御する - 推奨: **`strict-origin-when-cross-origin`**（モダンブラウザのデフォルトと同じ、明示する） - 機密情報を扱う管理画面では `same-origin` や `no-referrer` も検討 - 設定はサーバー側ヘッダで（meta タグより一貫適用される） ## まずは現状を把握しましょう 自社サイトに Referrer-Policy が設定されているかは、ドメイン番人の [Web セキュリティヘッダ 単発チェック](/security-headers/check) で 30 秒で確認できます。 設定支援が必要な場合は [Web セキュリティヘッダ診断＋設定支援](/contact)（3 万円〜）でご相談ください。CSP の入門は [CSP（Content-Security-Policy）とは？Web 担当者のための入門](/blog/csp-content-security-policy-toha)、HSTS は [HSTS の設定方法](/blog/hsts-settei-houhou)、クリックジャッキング対策は [X-Frame-Options と CSP frame-ancestors](/blog/x-frame-options-clickjacking) を、カメラ / マイク / 位置情報など機能を制限する [permissions-policy ヘッダー](/blog/permissions-policy-toha) も合わせて検討してください。 総合点検は [無料のドメイン診断](/diagnose)、SSL 単独は [SSL 単発チェック](/ssl/check) をご利用ください。