なぜ「Referer」は漏洩源となるのか？HTTPヘッダーが語るプライバシーの境界線
ネットワークエンジニアとして現場に立っていると、ふと「当たり前」すぎて見落としている仕様が、実は大きなセキュリティホールだったという事実に冷や汗をかくことがあります。その代表格が、HTTP/1.1から脈々と受け継がれている「Referer」ヘッダーです。
今日は、ブラウザが勝手に送信するこの情報が、Web API設計やインフラ運用においてどのようなリスクを孕んでいるのか、そして現代のエンジニアがどう防衛すべきかについて、腹を割って話しましょう。
—
1. Refererの正体：なぜ「スペルミス」が仕様になったのか
まずは基本の確認です。HTTPリクエストヘッダーの一つである `Referer` は、ユーザーが今見ているページに「どこからやってきたか」をサーバーに教えるためのものです。
ここで面白い（そして少し悲しい）歴史話を一つ。本来、英語のスペルは「Referrer」ですが、HTTP仕様策定時のタイポがそのままRFC（RFC 1945/2616）に刻印され、今も「Referer」というスペルでプロトコルに定着しています。
通信フローにおけるRefererの役割
ユーザーが `A.com` からリンクをクリックして `B.com` に移動した際、`B.com` 側のサーバーには以下のようなリクエストが到達します。
GET /api/v1/resource HTTP/1.1
Host: b.com
Referer: https://a.com/secret-page?user_id=12345 # ここが最大の問題！
User-Agent: Mozilla/5.0…
この「クエリパラメータまで含めて送信してしまう」という仕様が、機密情報漏洩の温床です。もしURLにセッションIDや個人情報が含まれていたら、リンク先の第三者サーバーにその情報が筒抜けになるのです。
—
2. 現場で使える防御術：Referrer-Policyの活用
この脆弱性を緩和するために登場したのが `Referrer-Policy` ヘッダーです。これを使えば、「どの程度まで遷移元URLを削って送信するか」をサーバー側（あるいはHTML側）で制御できます。
実践：ポリシーの設定例
Webサイトを運営しているなら、まずは最も安全な `strict-origin-when-cross-origin` を検討してください。
Nginx設定例:
全レスポンスにヘッダーを付与して、意図しない情報漏洩をブロック
add_header Referrer-Policy “strict-origin-when-cross-origin” always;
- `no-referrer`: 一切送信しません。最も安全ですが、ログ解析の精度が落ちます。
- `strict-origin-when-cross-origin`: 同一オリジンならURLを送信し、異なるドメインへの遷移時はドメイン名（origin）のみを送信します。現代のデファクトスタンダードです。
—
3. API開発者・フロントエンドのためのデバッグTips
開発中、自分のアプリがどのような情報を外部に飛ばしているかを確認するのは、エンジニアの嗜みです。
Python (Requests) で確認する
APIクライアントを作成する際、意図せずRefererを付与していないか確認するコードです。
import requests
セッション作成時にRefererが自動付与されていないかチェック
session = requests.Session()
response = session.get(‘https://target-api.com/data’)
実際に送られたヘッダーを覗き見る
print(response.request.headers.get(‘Referer’))
もし必要なら明示的に削除：del session.headers[‘Referer’]
ブラウザのFetch APIで試す
フロントエンド実装時、`referrerPolicy` プロパティを明示的に指定して通信を制御できます。
fetch(‘https://api.example.com/data’, {
method: ‘GET’,
// 通信ごとにポリシーを制御できる
referrerPolicy: ‘no-referrer’
}).then(res => console.log(‘送信制御完了’));
—
シニアエンジニアからの助言：ログと監視の視点
インフラ運用を担当していると、アクセスログに `Referer` が大量に記録されます。しかし、「ログには個人情報が含まれているかもしれない」という意識を常に持ってください。
1. マスキングの徹底: ログ集計基盤に流し込む前に、Refererに含まれるクエリパラメータを正規表現で削るパイプラインを組むこと。
2. セキュリティヘッダーの自動チェック: CI/CDパイプラインの中で、`curl` を使ってHTTPレスポンスヘッダーに `Referrer-Policy` が含まれているかテストするステップを組み込みましょう。
現場のワンライナー：ポリシーが設定されているか確認
curl -I https://your-site.com | grep Referrer-Policy
まとめ：ネットワークは「隠す」ことが正義になることもある
HTTP/1.1の設計思想は「オープン」でしたが、現代のWebは「プライバシー」を何よりも優先しなければなりません。Refererは便利な機能ですが、デフォルトの状態は「過剰な情報提供」です。
皆さんの管理するネットワークやアプリケーションが、ユーザーの意図しない情報を外に漏らしていないか。ぜひ今日の業務の合間に、レスポンスヘッダーを見直してみてください。こうした小さな積み重ねが、大規模なインシデントを防ぐ「防波堤」になるのです。
何か具体的なトラブルや、設定値で迷うことがあれば、またいつでも聞いてください。現場の知見を共有しましょう。
コメント