【入門編】HTTP/1.1のRefererヘッダーとプライバシー – HTTPプロトコル・通信規格実践ガイド

Webサイトを閲覧しているとき、私たちは意識せずに膨大な数の「手紙」をサーバーとやり取りしています。その中でも、ちょっとお節介で、時にプライバシーの脅威にもなり得る「Referer（リファラー）」というヘッダーをご存知でしょうか。

今日は、このRefererがなぜ生まれ、どのような危険を孕み、そして現代のエンジニアはどう対策すべきなのか。郵便配達の仕組みに例えながら、一緒に紐解いていきましょう。

—

HTTP/1.1という、今のWeb通信の礎を築いたルールの世界では、サーバーに対して「私はあなたのページを、このURLから辿ってきました！」という情報を送る仕組みがあります。これが`Referer`ヘッダーです。

現実世界で例えるなら、「紹介状」のようなものですね。

これがあるおかげで、サイト運営者は「うちのサイトは、SNSから見られているのか？それともGoogle検索からなのか？」という分析ができるようになります。マーケティングの世界では非常に便利なツールなのです。

—

便利なはずのRefererですが、時には「余計なことまで喋ってしまう」という問題が起きます。

例えば、あなたが会員制サイトの「設定変更ページ」にいるとしましょう。そのURLには、一時的な認証コードが含まれているかもしれません。
そのページから外部の広告バナーをクリックした瞬間、ブラウザは律儀に「設定変更ページから来ました！」という情報を、広告サーバーに送ってしまうのです。

もしそのURLにユーザーIDや機密情報が含まれていたら……？サーバー管理者は悪意がなくても、ログを解析すればあなたのプライベートな情報が筒抜けになってしまいます。これが、Web黎明期にはあまり意識されていなかった「Refererによる情報漏洩」の正体です。

—

「全部教えるのは危ないから、ルールを決めよう」ということで登場したのが、Referrer-Policyという新しい防衛線です。

かつては「送るか、送らないか」の二択しかありませんでしたが、今は「どの範囲までURLを教えるか」を細かく指示できるようになりました。

—

もしあなたがWebサイトの管理者なら、一度ブラウザの「開発者ツール（F12キー）」を開いてみてください。

1. 「ネットワーク」タブを開く。
2. 適当なリクエストを選択する。
3. 「ヘッダー（Headers）」の中にある `Referer` を探してみる。

もし、意図せず長いURLがそのまま垂れ流されているなら、Webサーバーの設定（NginxやApache）でヘッダーを制御するか、HTMLの `` タグでポリシーを明示的に設定しましょう。

サーバー全体で強制的にポリシーを適用したい場合は、設定ファイルにこう書き加えます。

サーバーのレスポンスヘッダーとして、ポリシーを強制する設定
add_header Referrer-Policy “strict-origin-when-cross-origin”;

—

HTTP/1.1が策定された当初、インターネットは「信頼できる場所」という性善説が強く働いていました。しかし、現在のWebはより複雑で、プライバシー保護が絶対的な命題になっています。

Refererは、ネットワークの先にある「文脈」をサーバーに伝えてくれる優秀な案内役です。しかし、その案内役が誰に何を話しているのかを管理するのは、私たちエンジニアの責任です。

「何が送られているのか」を可視化し、「どこまで送っていいのか」を制限する。この当たり前の積み重ねが、ユーザーの安心を守る最高のインフラ作りにつながります。

さあ、皆さんのサイトのRefererは、誰にどんな情報を渡していますか？ぜひ一度、覗いてみてくださいね。