こんにちは。現場の最前線でセキュリティの泥臭い対応に追われつつ、技術の啓蒙にも情熱を燃やすエンジニアです。
今日は、開発者なら誰もが一度は耳にする「XSS（クロスサイトスクリプティング）」という言葉と、意外と見落としがちな「Referrer-Policy」という防犯対策についてお話しします。
専門用語の羅列は一切なし。まずは、身近な「家の鍵」に例えて、この仕組みを紐解いていきましょう。
—
1. XSSと「泥棒の置き土産」
XSS（クロスサイトスクリプティング）をシンプルに言うなら、「Webサイトの隙間から、悪いスクリプト（命令）を忍び込ませる攻撃」のことです。
あなたが家から出るとき、玄関の鍵を閉めますよね。でも、もし鍵穴が壊れていて、誰かがそこに「開けっ放しにする魔法」をかけたらどうなるでしょう？ あなたの家（Webサイト）に訪れたゲストが、その魔法のせいで泥棒に大切な宝石（セッションIDや個人情報）を盗まれてしまうかもしれません。
これがXSSの恐ろしさです。攻撃者はユーザーのブラウザ上で勝手にコードを実行させ、そのユーザーになりすまして操作をしたり、秘密の情報を盗み出したりします。
2. なぜ「リファラー（Referer）」が危険なのか？
ここで、今回の主役である「Referer（リファラー）」の話をしましょう。
ブラウザには「直前までどのページにいたか」を、次のWebサイトに教えてあげるという親切な機能があります。例えば、あなたが https://example.com/login?token=secret123 というURLから別のサイトへ移動すると、移動先のサイトには「あ、このユーザーはトークン付きのページからやってきたんだな」という情報が筒抜けになります。
これ、泥棒からすれば「宝の地図」を渡されているようなものです。攻撃者はわざと自分の管理するサイトへユーザーを誘導し、そのURLに含まれる機密情報を盗み取ろうとします。
3. 「Referrer-Policy」という防犯カメラと自動シャッター
この「勝手に情報を漏らしてしまう癖」を抑え込むのが、Referrer-Policy です。
例えるなら、「家から出る際、訪問先に『どこの部屋から来たか』を伝えないようにする防犯フィルター」です。これを設定しておけば、URLに重要な情報が含まれていても、相手には「どこから来たか」を教えないようにブロックできます。
どうやって設定するの？
Webサーバーの設定、あるいはHTMLのメタタグで簡単に実装できます。現場で一番おすすめなのは、strict-origin-when-cross-origin という設定です。
HTMLの に書く場合
Webサーバー（Nginx）で設定する場合
HTTPレスポンスヘッダーに設定を追加します
add_header Referrer-Policy “strict-origin-when-cross-origin” always;
この設定の何がすごいの？
この strict-origin-when-cross-origin は、こんな風に賢く動きます。
- 同じサイト内での移動： どのページから来たか、詳しく教えます（利便性は損なわない）。
- 別のサイトへの移動： URLのパラメータ（機密情報）を削り取り、「このドメインから来たよ」という最低限の情報だけ伝えます。
- 暗号化されていないサイトへの移動： 情報漏洩を防ぐため、一切の情報を教えません。
まさに、「親しい仲間には挨拶するけれど、見知らぬ場所へ行くときは素性を隠す」という、非常にバランスの良い防犯設定なのです。
—
4. 最後に：セキュリティは「積み重ね」です
XSS対策として、入力値のチェックやHTMLエスケープ（特殊文字を無害化すること）は必須ですが、それだけで完璧とは言い切れません。システムは常に複雑で、どこかに綻びが生じる可能性があります。
だからこそ、今回紹介した Referrer-Policy のような「多層防御」の考え方が重要になります。
「これひとつで絶対安全」という魔法はありません。でも、鍵を二重にする、防犯カメラを付ける、窓に格子をはめる……そんな泥臭い積み重ねこそが、ユーザーの信頼を守る唯一の道です。
まずは今日、あなたのWebサイトのヘッダーにこの設定が入っているか、確認することから始めてみてください。一歩ずつ、一緒に守りを固めていきましょう！
—
執筆後記：セキュリティ担当者としての私のモットーは「性悪説に基づき、性善説で運用する」です。技術を過信せず、常に「もしも」を想定して設計していきましょう。何か不安なことがあれば、いつでも相談してくださいね。
コメント