境界線上の脆弱性：Referer漏洩が招く「見えない攻撃」とReferrer-Policyの深淵
Webセキュリティの世界において、XSS（クロスサイトスクリプティング）はもはや「古典」として片付けられがちだ。しかし、現場の最前線でインシデント対応をしている諸君なら知っているはずだ。反射型や格納型といった教科書的な脆弱性が封じ込められたとしても、「HTTPヘッダー」というプロトコルレベルの仕様が引き起こす情報漏洩は、依然として攻撃者にとって格好のターゲットであるという事実に。
今回は、URLパラメータに含まれる機密情報がRefererヘッダーを通じてサードパーティへと流出するリスク、そしてそれを制御するためのReferrer-Policyの戦略的実装について、アーキテクトの視点から紐解いていく。
—
1. なぜ「URL」は機密情報の墓場となるのか
多くの開発者は、機密情報をPOSTボディに含めるべきだと理解している。しかし、現実のビジネスロジックは往々にして複雑だ。リセットトークン、セッションIDの一部、あるいはPII（個人特定情報）が、クエリパラメータとしてURLに埋め込まれた状態で画面遷移が発生することは珍しくない。
ここでの致命的な盲点は、HTTPプロトコルの仕様上、ブラウザは遷移先のサーバーに対して「遷移元ページ（Referer）」を律儀に教えようとすることだ。
攻撃者の視点：中間者とログの罠
攻撃者は、あなたが構築したアプリケーションの脆弱性を直接突く必要はない。あなたが読み込んでいるサードパーティのスクリプト（広告、解析ツール、あるいは侵害されたCDN上のライブラリ）に細工をするか、あるいは遷移先のサーバーログを覗き見るだけでいい。そこに記されたRefererヘッダーには、URLに付与されたトークンやユーザーIDが丸裸で記録されている。これは、セッションハイジャックやアカウント乗っ取りの踏み台として、攻撃者にとっては「宝の山」なのだ。
—
2. Referrer-Policyによる「通信の遮断」と「情報の限定」
現代の防衛アーキテクトにとって、Referrer-Policyの導入は単なる設定変更ではない。これは、「ブラウザの自律的な通信行動をプロトコル層で制限する」という、極めて強力なガードレイルだ。
推奨されるモダンな実装設定
セキュリティの多層防御を考える際、最も推奨されるのは strict-origin-when-cross-origin である。
サーバーサイドのHTTPレスポンスヘッダー設定例
セキュリティ要件が高いアプリケーションでは、以下の設定をベースラインとする
Referrer-Policy: strict-origin-when-cross-origin
strict-origin-when-cross-originの真意- 同一オリジン内: フルパス（クエリ付き）を送信する（利便性維持）。
- HTTPS → HTTPSへのクロスオリジン: オリジン（ドメイン部分）のみを送信し、パスやクエリを削除する（情報保護）。
- HTTPS → HTTPへのダウングレード: Refererヘッダーを一切送信しない（プロトコルレベルの安全性担保）。
もし、アプリケーションの要件がより厳格であれば、no-referrer（一切送らない）を選択すべきだが、UXや解析データへの影響を考慮すると、まずは strict-origin-when-cross-origin を適用し、監査ログで「Referer漏洩によるセッション情報の流出がないか」を定期的にスキャンするフローを構築するのが、現実的な防衛ラインとなる。
—
3. 実務への落とし込みと監査の観点
アーキテクトとして、このポリシーを導入する際は単にヘッダーを付与して満足してはいけない。以下の3つのチェックポイントを自問自答せよ。
① CSP（Content Security Policy）との連携
XSS防御の要であるCSPとReferrer-Policyは共依存関係にある。script-src で信頼できないドメインを排除しつつ、Referrer-Policyで情報の露出を最小化する。この両輪が回っていないシステムは、防御層に「穴」がある状態だ。
② 生成AIとプロンプトインジェクションへの対策
最近のトピックとして、生成AIを組み込んだWebアプリでは、URLにコンテキストを保持させるパターンが多い。このとき、Refererを介してプロンプトや推論結果の一部が外部のサードパーティへ渡るリスクを考慮しなければならない。ユーザーの意図しない情報がRefererに乗ることを防ぐため、UI側の遷移ロジックを「URLパラメータを使わない設計（State管理の分離）」へと移行することが、究極の対策となる。
③ 監査スクリプトの自動化
CI/CDパイプラインの中に、以下のような簡易的なチェックを組み込むことを推奨する。
監査用ワンライナー（ダミー）
本番環境の全レスポンスヘッダーをクロールし、不適切なポリシー設定を検知する
curl -I -s https://your-app.com/ | grep -i “Referrer-Policy” || echo “CRITICAL: Policy Missing!”
—
結びに：境界線は「動的」に守れ
セキュリティの歴史は、仕様の「隙間」を突く攻撃と、それを埋める防衛のイタチごっこだ。Refererヘッダーという、Web黎明期からの古典的な仕組み一つとっても、現代のアーキテクチャではこれだけの設計上の配慮が求められる。
技術は常に進化する。だが、「ブラウザが何を送るのか、サーバーが何を許可するのか」という低レイヤの通信挙動を把握し続けることこそが、最高峰のエンジニアが持つべき「眼」だ。
次にコードをコミットする際、ぜひ思い出してほしい。そのURLパラメータは、誰に見られるべきものなのか。それを決めるのは、ブラウザのデフォルト挙動ではなく、君の書いたポリシーであるべきだということを。
コメント