玄関の鍵を閉めても「どこへ行くか」まで覗かれていませんか？：Referrer-Policyの基礎と実践
こんにちは。セキュリティの世界で長く泥臭い現場を見てきた者です。
今日は、開発現場でつい見落とされがちな「情報の出しすぎ」についてお話ししましょう。皆さんは、自分の家から外出する際、玄関の鍵をしっかり閉めますよね？ でも、もし「今から隣の町へ行くよ」と書いた看板を背中に貼り付けて歩いていたらどうでしょう？ どこで誰に狙われるか分かったものじゃありません。
Webの世界における「Refererヘッダー」は、まさにその「背中の看板」です。今回は、これを適切にコントロールする「Referrer-Policy」という防犯術について、一歩ずつ学んでいきましょう。
—
そもそも「Refererヘッダー」って何者？
Webサイトを閲覧しているとき、ブラウザは「今どこのページから飛んできたのか」という情報を、次のサイトに自動的に伝えています。これがReferer（リファラー）ヘッダーです。
例えば、パスワード再発行ページに「https://example.com/reset-password?token=abcdefg12345」のようなURLがあったとします。このURLには、あなたの秘密のトークンが含まれていますよね。
この状態で外部の広告バナーや解析ツール（Google Analyticsなど）へ移動すると、ブラウザは親切心で「このトークン付きのURLから来ましたよ！」と、外部サーバーにその秘密を教えてしまうのです。
もしその外部サーバーが悪意を持っていたら？ あるいは、通信の途中で誰かに盗み見られていたら？ まさに、秘密の鍵を他人に手渡しているのと同じ状態なのです。
—
防御の第一歩：Referrer-Policyで「看板」を隠す
この情報漏洩を防ぐために生まれたのが「Referrer-Policy」です。これはWebサーバー側からブラウザに対して、「外部へ行くときは、どこまで情報を伝えていいか」というルールを指示するものです。
よく使う設定（ルール）の例
今のWeb開発で標準的に使われている、おすすめの設定を紹介します。
strict-origin-when-cross-origin（これ一択でOK！）- 同じサイト内ならURLを詳しく伝えますが、外部へ行くときは「ドメイン名（例:
https://example.com）」までしか教えません。これなら、URL末尾の秘密のトークンは隠しつつ、どこから来たかの最低限の記録は残せます。 no-referrer- 「一切教えない」という最強のガードです。プライバシー重視の極致ですね。
—
実装してみよう：設定は意外と簡単です
難しく考える必要はありません。Webサーバーの設定ファイルに1行追記するだけです。
Apacheの場合（.htaccess）
外部への情報送信をドメイン名のみに制限する
Header set Referrer-Policy “strict-origin-when-cross-origin”
Nginxの場合（nginx.conf）
全てのレスポンスにこのポリシーを付与する
add_header Referrer-Policy “strict-origin-when-cross-origin”;
HTMLのmetaタグでも設定可能（個別のページでやりたい場合）
—
なぜこの設定が「セキュリティのプロ」に重視されるのか
皆さんが開発するアプリケーションには、日々多くのユーザーが訪れます。その一人ひとりの「どこへ行ったか」というプライバシーや、URLに含まれる認証情報を守るのは、開発者である皆さんの責任です。
インジェクション攻撃のように「派手に壊される」わけではありませんが、この種の「情報漏洩」は静かに、そして確実にユーザーの信頼を削り取ります。
「まあ大丈夫だろう」と放置せず、今日から玄関の看板を整理する習慣をつけてみてください。小さな設定一つが、何万人ものユーザーを泥棒から守る盾になります。
一歩ずつ、セキュアな実装を積み重ねていきましょう。応援していますよ！
コメント