なぜ「Refererヘッダー」が、あなたのアプリの急所になるのか？
現場のエンジニア諸君、お疲れ様。今日は多くの開発者が「ブラウザが勝手にやってくれる便利な機能」程度にしか考えていない、Refererヘッダーの裏側に潜むリスクについて話そう。
Webアプリの設計において、攻撃者は常に「認証済みのセッション」や「URLに含まれるトークン」を狙っている。もし、君たちが開発しているアプリケーションから外部の広告スクリプトや画像へのリクエストが発生したとき、そのURLに機密情報（例：?token=abc123xyz や ?user_id=999）が含まれていたらどうなるか？
そのURLは、そのまま外部のWebサーバーのアクセスログに記録される。もしその外部サイトが攻撃者の息のかかった場所であれば、君たちのユーザーのセッションは即座にハイジャックされることになる。これが、Refererヘッダーを巡る情報漏洩の現実だ。
—
攻撃シナリオ：Referer経由のトークン窃取（PoC）
例えば、パスワードリセット用のURLが https://example.com/reset?token=secret_token_12345 だとしよう。ユーザーがこのページを開いた際、ページ内に外部ドメインの画像が一つでも埋め込まれていれば、ブラウザはその外部ドメインに対して Referer: https://example.com/reset?token=secret_token_12345 というヘッダーを送信する。
攻撃者は、この外部ドメインのログを解析するだけで、全ユーザーのトークンを収集できる。SQLインジェクションのように派手なコードを送り込む必要すらない。ただ待つだけで、機密情報が向こうから飛んでくるのだ。
—
防御の要：Referrer-Policyの極意
この漏洩を止めるための確実な手段が、HTTPレスポンスヘッダーの Referrer-Policy だ。これを使うことで、ブラウザに対して「どの範囲までRefererを送っていいか」を厳格に指示できる。
1. Nginxでの設定（インフラ層での一括適用）
まずは、アプリケーションのコードをいじる前に、Webサーバー側で「デフォルトの安全圏」を作っておくのがプロの仕事だ。Nginxの設定ファイルに以下を追記してくれ。
Nginx設定ファイル (nginx.conf または sites-available/xxx)
strict-origin-when-cross-origin:
同一オリジンならURLをフル送信、クロスオリジンならホスト名のみ(https://example.com/)を送信
パスやクエリパラメータは隠蔽されるため、非常に安全かつ実用的
add_header Referrer-Policy “strict-origin-when-cross-origin” always;
2. PHPアプリケーションでの実装（動的な制御）
特定のページでどうしてもRefererが必要、あるいは逆に一切漏らしたくないといったケースでは、PHP側で制御する。
3. JavaScriptでの動的な制御（外部リンクを貼る際のTips）
フロントエンドエンジニアが意識すべきは、外部サイトへのリンクを貼る際だ。HTMLのタグ属性で個別に制御できることを忘れてはならない。
—
なぜこの設定が「最強」なのか
私が strict-origin-when-cross-origin を推奨するのには理由がある。
no-referrerにしすぎない: 外部サイト側で「どこから来たか」の解析ができなくなると、マーケティングやアクセス解析に支障をきたすことがある。- 機密情報を守る: パスやクエリパラメータを削ぎ落とすことで、
tokenやidといった攻撃者が最も好む情報を確実に遮断できる。
セキュリティとは「利便性と安全性のバランス」を極めることだ。何もかも禁止すればシステムは使い物にならなくなる。しかし、今回紹介した設定は、現代のWeb標準において、「何も損なわずに、最大のリスクだけを排除する」ための、いわば黄金比だ。
現場のリーダーへ：最後に一言
コードを書くとき、「このURLに機密情報が含まれていないか？」を自問自答する癖をつけてほしい。URL設計（RESTfulなAPI設計など）において、機密情報をクエリパラメータに含めること自体が、そもそもアンチパターンであることも理解しておくこと。
インシデントは常に「想定外」の場所から起きる。だが、今回のような「想定できる穴」を塞いでおくだけで、君たちのチームの防御力は格段に上がるはずだ。さあ、設定ファイルを書き換えて、デプロイしよう。それが、守りの第一歩だ。
コメント