パケットの足跡を消せ：HTTP/1.1 `Referer` の闇と `Referrer-Policy` によるインフラ防衛術
ネットワークの深淵を覗くとき、私たちはしばしば「目に見えるデータ」だけに気を取られがちだ。SYN/ACKのハンドシェイク、TLSの鍵交換、そして暗号化されたアプリケーション層のペイロード。しかし、パケットアナライザを叩き、TCPストリームを再構築したときに見えてくるメタデータの数々は、時にユーザーのプライバシーという極めて機密性の高い情報を、無防備なクリアテキスト（あるいはTLSトンネルの保護下とはいえ第三者サーバー）へと暴露している。
その代表格が、HTTP/1.1の歴史的遺産にしてプライバシーのトロイの木馬――`Referer` ヘッダーだ。
今回は、この `Referer` が抱える致命的なリスクの正体をパケットレベルで解剖し、現代のWebアーキテクチャにおいてインフラエンジニアやテックリードが講じるべき防衛策、そして `Referrer-Policy` による厳格なコントロール手法について、実務に即したディープな知見を交えて解説しよう。
—
1. なぜ `Referer` は漏洩するのか？：HTTP/1.1の設計思想とパケットの現実
まず、歴史と仕様の再確認から始めよう。HTTP/1.1（RFC 7231）において、`Referer`（スペルミスがそのまま標準化した歴史的経緯を持つ）は、リクエストを発行した元のリソースのURIを示すために定義された。
ユーザーが `https://example.com/articles/secret-pension-plan` というページに配置された外部サイトへのリンクを踏んだ瞬間、ブラウザは次のようなHTTPリクエストをターゲットサーバーへ送出する。
GET /product/security-audit HTTP/1.1
Host: vendor.example.org
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0
Accept: text/html,application/xhtml+xml
Referer: https://example.com/articles/secret-pension-plan
Accept-Language: ja,en-US;q=0.7,en;q=0.3
Connection: keep-alive
この瞬間、`vendor.example.org` のアクセスログ（あるいはJavaScriptの `document.referrer`）には、ユーザーが「どの文脈（どの記事、どの検索クエリ、どのパラメータ）から遷移してきたか」が丸見えになる。
プライバシーリスクの本質：URLに内包される「秘密」
現代のWebアプリケーションでは、URLは単なるリソースの居場所（Locator）にとどまらない。GETパラメータやパスの構造自体に、以下のような機密情報が埋め込まれているケースが多々ある。
- セッションIDやワンタイムトークン（設計不良によるURLパラメータ漏洩）
- プライベートな検索クエリ（`?q=うつ病の治療法` や `?keyword=競合他社M&A`）
- 内部IDやテナント情報（`https://app.internal.corp/users/98765/edit`）
これが外部のCDNや広告・アクセス解析サーバーに流出した場合、それは単なる「ブラウジング履歴の追跡」にとどまらず、企業の内部構造の露呈や、個人の思想・健康状態の特定といった深刻なセキュリティインシデントに直結する。
—
2. トランスポート層とTLSにおける「安全神話」の崩壊
「うちは全編HTTPS（HSTS強制）で暗号化しているから、中間者攻撃（MitM）でパケットが盗聴されることはない。だからRefererも安全だ」――そう考えているインフラエンジニアがいるなら、今すぐその認識を改める必要がある。
TLS（Transport Layer Security）は、クライアントとサーバー間の通信経路（トランスポート層の上位）を暗号化する。Wiresharkでキャプチャしても、TLSレコード層の中身は暗号化された暗号文（Ciphertext）でしかない。
[Client] — (Encrypted TLS Record: Referer: https://secret…) —> [External Server]
しかし、これは「通信経路上での盗聴を防いでいる」に過ぎない。
リクエストを受け取った `External Server` のアプリケーション層、あるいはその手前のリバースプロキシやCDNのエッジサーバーにおいて、`Referer` ヘッダーは復号され、明確な文字列として存在している。つまり、リンク先のサーバー運営者が意図的あるいは脆弱性によってそのログを収集・外部流出させた場合、暗号化は何の盾にもならないのだ。
さらに、プロトコル間の遷移における「リファラー漏洩の鉄則」が存在する。
- HTTPSからHTTPSへの遷移: セキュリティレベルが同等であるため、デフォルトで `Referer` は送信される。
- HTTPSからHTTPへの遷移（ダウンウインド）: 暗号化されたセキュアなコンテキストから、暗号化されていない平文のネットワーク空間へ遷移する際、ブラウザはセキュリティ低下を検知し、原則として `Referer` ヘッダーを一切送信しない仕様になっている（Mixed Content対策の一環でもある）。
しかし、この仕様の隙をつくリスクや、同一オリジン・クロスオリジン間での意図しない情報伝播を制御するために、私たちは `Referrer-Policy` という強力な武器をインフラおよびアプリケーション層で強制しなければならない。
—
3. `Referrer-Policy` による防衛ラインの構築
モダンブラウザは、HTTPレスポンスヘッダーやHTMLのメタタグによって指定される `Referrer-Policy` の指示に従い、送信する `Referer` の粒度を制御する。インフラアーキテクトとして、このポリシーをWebサーバーやCDNのエッジ（Nginx, Envoy, Cloudflare Workers等）でグローバルに強制することが求められる。
主要なポリシーの挙動と選択基準
1. `no-referrer`
- パケットに `Referer` ヘッダーを一切含めない。プライバシー保護の観点では最強だが、アクセス解析等で流入元が完全にブラックボックス化するトレードオフがある。
2. `strict-origin-when-cross-origin`（現代の多くのブラウザにおけるデフォルト）
- 同一オリジン（Same-Origin）へのリクエストにはフルパス（`https://example.com/path/to/page`）を送信。
- クロスオリジン（Cross-Origin）へのリクエスト、かつHTTPSからHTTPSへの遷移では、オリジン（`https://example.com/`）のみを送信。
- HTTPSからHTTPへのダウングレード時は送信しない。
3. `same-origin`
- 同一オリジン内でのみ `Referer` を送信し、外部サイトへは一切送信しない。外部へのリンクが多いメディアサイト等でプライバシーを守るための現実的な解。
—
4. 実践：NginxおよびWebアプリケーションにおける実装と検証
では、実際のインフラ環境でどのようにこのポリシーを適用し、パケットレベルで意図した動作になっているかを確認するかを見ていこう。
Nginxでのグローバルヘッダー設定
すべてのレスポンスに対して、強固な `Referrer-Policy` を強制するNginxの設定スニペットだ。ここでは、外部への情報漏洩を最小限に抑えつつ、同一オリジン内での利便性を保つ `strict-origin-when-cross-origin` を採用している。
server {
listen 443 ssl http2;
server_name secure.example.com;
ssl_certificate /path/to/cert.pem;
ssl_certificate_key /path/to/key.pem;
# — セキュリティヘッダーの強制 —
# Referrer-Policyの鉄則設定
add_header Referrer-Policy “strict-origin-when-cross-origin” always;
# ついでに他のモダンセキュリティヘッダーも付与しておく
add_header X-Content-Type-Options “nosniff” always;
add_header X-Frame-Options “SAMEORIGIN” always;
add_header Content-Security-Policy “default-src ‘self'” always;
location / {
root /var/www/html;
index index.html index.htm;
}
}
HTMLタグ単位での制御（細やかな調整が必要な場合）
特定のリンクやページ単位で挙動を制御したい場合は、HTMLの `meta` タグや `a` タグの `referrerpolicy` 属性を利用する。
—
5. パフォーマンスとセキュリティのトレードオフ、そしてネクストステップ
インフラアーキテクトの視点として、セキュリティヘッダーの付与がパフォーマンスに与える影響についても言及しておこう。
`Referrer-Policy` のようなHTTPレスポンスヘッダーの追加は、TCPパケットのMSS（Maximum Segment Size）やMTUの制約（通常1500バイト）の範囲内であれば、初期のTCP Slow Startにおける初期輻輳ウィンドウ（IW10など）のセグメント数に影響を与えない限り、実質的なレイテンシ（RTT）の増加は無視できるレベルだ。HTTP/1.1のコネクション再利用（Keep-Alive）下では、ヘッダーの数バイトの増加がスループットを圧迫することはない。
しかし、セキュリティを意識するあまり全てのリンクで `no-referrer` を強制すると、マーケティング部門やグロースハックチームからの突き上げを食らうことになる。「どこからユーザーが流入したのかコンバージョンが追えない」というビジネス上の要求と、ユーザーのプライバシー保護・情報漏洩リスクの軽減。この相反する2つの要件を調停するのが、まさにテックリードやアーキテクトの腕の見所だ。
アーキテクトへの提言
1. URL設計の原則を見直す: GETクエリパラメータに個人情報やセッションIDを含める設計（いわゆるSession ID in URLや、過剰なトラッキングパラメータの乱用）を廃止し、POSTボディやAuthorizationヘッダー、あるいはCookie（SameSite属性付き）に移行する。これにより、万が一 `Referer` が外部に漏洩した際のリスクを根本から無力化できる。
2. エッジでのポリシー強制: アプリケーションコードの修正に頼るのではなく、Cloudflare、CloudFront、FastlyなどのCDNエッジや、Nginxなどのリバースプロキシ層で `Referrer-Policy` を一括送出・強制するパイプラインを構築する。
パケットは嘘をつかない。だが、パケットが運ぶメタデータが誰の手に渡るかは、私たちインフラストラクチャーの設計にかかっている。プロトコルの隅々まで目を配り、セキュアで高パフォーマンスなネットワークをデザインし続けよう。
コメント