【入門編】Refererヘッダーの漏洩リスクとReferrer-Policyによる制御 – アプリケーションセキュリティ & 安全な開発防御ガイド

こんにちは！現場でセキュリティの最前線に立っていると、「まさかそんなところから情報が漏れるなんて……」というケースによく遭遇します。

開発を始めたばかりの頃、URLの末尾に ?user_id=12345&token=abcde... のように情報を詰め込んだことはありませんか？実はこれ、あなたの家の鍵を握りしめたまま、通りすがりの泥棒にわざわざ見せびらかしているようなものなんです。

今回は、Webサイトのセキュリティにおける盲点、「Referer（リファラー）漏洩」について、身近な例えを交えながら、どうやって防ぐのかを一緒に見ていきましょう。

—

Webブラウザには、「今どこのページから飛んできたのか」を次のサイトに教える「Referer（参照元情報）」という仕組みがあります。

これを例えるなら、「紹介状」です。
あなたが友人宅を訪ねるとき、玄関で「〇〇さんの紹介で来ました」と言いますよね。それがRefererです。通常は便利なものですが、もしその紹介状に「あなたの家の合鍵」や「金庫の暗証番号」が書かれていたらどうでしょう？

URLパラメータに機密情報（セッションIDや個人情報など）を含めた状態で別のページへ遷移すると、その機密情報がRefererという名の「紹介状」に載せられ、遷移先のWebサイトに筒抜けになってしまうのです。

—

ここで登場するのが、Webサイトの代表的な脅威である「クロスサイトスクリプティング（XSS）」です。

もし、あなたが遷移先のサイトの運営者だったら？あるいは、もし遷移先のサイトが悪意のある攻撃者によって改ざんされていたら？
あなたのサイトから送られてきたReferer（機密情報入り）を、攻撃者はログとしてごっそり回収します。

「URLに情報を入れるのは便利」という油断が、結果としてユーザーの個人情報を泥棒に手渡す手口に繋がってしまうわけですね。

—

URLに機密情報を含めない設計がベストですが、どうしても避けられない場合や、多層防御（念には念を入れること）のために役立つのが「Referrer-Policy」です。

これはブラウザに対して、「紹介状（Referer）をどの範囲まで渡していいか」というルールを定義する設定です。

今のWeb開発現場で「まずはこれだけは設定しておこう！」という鉄板の設定を3つ紹介します。

no-referrer: 「一切紹介状を渡さない」。一番安全ですが、解析ツール（Google Analyticsなど）が動かなくなる可能性があります。
strict-origin-when-cross-origin: （おすすめ！） 「同じサイト内なら詳しく教えるけど、外部サイトに行くときは『ドメイン名（〇〇.com）』だけ教えるよ」。これが現在のモダンなWebサイトの標準的な設定です。
no-referrer-when-downgrade: 昔のデフォルト。HTTP通信に落ちた時に情報を渡さない仕組みですが、今はあまり使いません。

—

設定はとても簡単です。Webサーバー（NginxやApache）や、アプリケーションのヘッダーに追加するだけで完了します。

全てのレスポンスにセキュリティヘッダーを付与
add_header Referrer-Policy “strict-origin-when-cross-origin”;

これを設定しておくだけで、仮にURLにうっかり機密情報を入れてしまっても、外部サイトには「どのページから来たか（ドメイン名）」までは伝わりますが、具体的な「パラメータ（機密情報）」は隠されるようになります。

—

セキュリティ対策において完璧なゴールはありません。今回紹介した「Referrer-Policy」も、万能薬ではなく「防犯カメラを増設する」ようなものだと考えてください。

1. URLパラメータに機密情報は絶対に入れない（これが一番の防犯！）
2. 万が一のためにReferrer-Policyを設定する（これで二重の備え！）

この二段構えを意識するだけで、あなたの開発するアプリケーションの信頼性はグッと高まります。最初は難しく感じるかもしれませんが、こうして一つずつ「穴」を塞いでいくプロセスこそが、エンジニアとしての確かな実力になっていきますよ。

一緒に、安全で頼られるWebの世界を作っていきましょう！応援しています！