/mypage トークン漏えい（Referrer）問題の解説

目的

/mypage に含まれる公開トークンが、外部リソースへのアクセス時に Referer として送信されてしまうリスクを理解し、対策の選択肢と影響を整理する。

前提

• /mypage は https://example.com/mypage/<public_token> の形式で公開される
• public_token は「知っている人がアクセスできる」認可トークン（実質的なパスワード）

用語

• Referer ヘッダー
  • ブラウザが別のリソースを取得する時に「どのページから来たか」を送る HTTP ヘッダー
  • 誤字だが仕様名が Referer
• Referrer-Policy
  • Referer ヘッダーに何を載せるかを制御するポリシー
  • 例: no-referrer, strict-origin-when-cross-origin
• Origin
  • https://example.com のようにスキーム + ホスト + ポートのみ

何が起きるか

/mypage ページに 外部リソース（例: Google Fonts）があると、ブラウザはその外部 URL へリクエストを送る。既定の設定次第では Referer に フルURL が含まれ、/mypage/<public_token> が外部に送信されることがある。

影響

• トークンが外部ログに残る
• 第三者がトークンを知ると /mypage を閲覧できる
• /mypage から公開スケジュール API を操作できる場合、空き時間の作成や削除が可能になる

具体的な被害例

• CDN/外部サービスのログにトークンが保存され、そこから漏えい
• 共有されたログや可視化ツールからトークンが発見される
• 漏えい後に候補者の選考状況やスケジュール情報が第三者に見られる

典型的な対策

1. Referrer-Policy を no-referrer にする

• 最も確実。外部に Referer を一切送らない
• デメリット: 外部サービスへの参照情報が完全に消える

2. strict-origin-when-cross-origin にする

• 外部には Origin のみ送信（パスは送らない）
• 実運用の妥協案としてよく使われる

3. 外部リソースを削減・自己ホスト化

• フォントや画像を自前配信にすれば Referer を外に送らない
• ただし運用コストが増える

4. CSP (Content-Security-Policy) で外部通信先を制限

• 許可ドメインを最小限にする
• Referer そのものは消えないが漏えい範囲を限定できる

本プロジェクトでの推奨

• アプリ側: frontend/index.html に <meta name="referrer" content="no-referrer"> を追加
• インフラ側: レスポンスヘッダー Referrer-Policy: no-referrer を付与
• 可能なら外部フォントの自己ホスト化も検討

確認方法

• ブラウザの DevTools (Network) で外部リソースの Request Headers を確認
• Referer が空、または Origin のみになっていることを確認

注意点

• ブラウザの既定ポリシーは環境差があるため、明示設定が安全
• /mypage は「トークン知識＝権限」モデルなので、URL漏えいは即座に被害につながる