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

リンクの裏側で何が起きているか？：Refererヘッダーが暴くプライバシーの闇と実務的な防衛策

ネットワークエンジニアとして現場を渡り歩いていると、「なぜか本番環境のアクセスログに社内システムのプライベートなURLが混ざっている」「意図しない外部の広告サーバーへ機密情報が流出している」といったインシデントに直面することがあります。

その犯人の多くは、Webブラウザが何気なく、しかし忠実に送信している `Referer`（リファラー）ヘッダー です。

今回は、HTTP/1.1の基本仕様であるこの `Referer` が抱えるプライバシーリスクの正体を暴き、現代のWebインフラにおいて私たちがどのようにこれをコントロールすべきか、実務に直結する知見を交えて徹底解説します。

—

1. Refererヘッダーの基本メカニズムとRFCの仕様

なぜスペルが「Referrer」ではなく「Referer」なのか？

まず雑学的ながら重要な歴史的背景として、HTTP仕様（RFC 1945のHTTP/1.0で初登場）を策定する際、単語の綴りを `Referrer` から `Referer` へ盛大にスペルミスしたまま標準化されてしまったという歴史があります。現在の仕様（RFC 7231など）でも、下位互換性を維持するために `Referer` という不完全なスペルがそのまま使われ続けています。

パケットの動き：Refererはいつ送信されるのか？

ユーザーがWebサイト上のリンクをクリックしたり、JavaScriptからリクエストが飛んだりしたとき、ブラウザは「自分が今、どのページのどこから来たのか」をサーバーに伝えます。

[User Browser] — ( GET /api/data HTTP/1.1
Host: example.com
Referer: https://app.example.com/dashboard/settings
) –> [Web Server / API]

この時、リクエストヘッダーに含まれる `Referer: https://app.example.com/dashboard/settings` こそが、リンク元（オジリナル）のURLです。

実務で頻発するプライバシーリスクとセキュリティ懸念

この `Referer` は、アクセス解析や「どのページから流入したか」を測るマーケティングの観点では非常に便利ですが、エンジニアの視点から見ると「爆弾を抱えた仕様」と言えます。

1. URLに含まれる機密情報の漏洩
パスワードリセットのトークンや、セッションID、検索クエリ（`?q=confidential_keyword`）などがURLのパスやクエリパラメータに含まれている場合、そのまま外部サイトへ `Referer` として送信されてしまいます。
2. クロスサイト・情報漏洩（Cross-Origin Information Leakage）
自社サイトから外部のCDNやサードパーティ製ウィジェットへ画像やスクリプトを読み込ませた際、ユーザーの閲覧している機密性の高いページURL（例: `https://bank.example.com/account/transfer?to=12345`）が、外部ベンダーのサーバーに丸見えになります。

—

2. 実務で直面するトラブルと検証用コード

百聞は一見に如かず。実際に `Referer` がどのように送受信されるのか、開発やデバッグで使うコードを使って確認してみましょう。

① Python (Flask) によるサーバー側のRefererキャプチャ

まずは、クライアントから送られてくる `Referer` を受け取る簡単なバックエンドAPIをFlaskで立ててみます。

from flask import Flask, request, make_response

app = Flask(__name__)

@app.route(‘/api/track’, methods=[‘GET’])
def track_request():
# リクエストヘッダーからRefererを取得（存在しない場合はNone）
referer_url = request.headers.get(‘Referer’, ‘Refererヘッダーはありません’)
user_agent = request.headers.get(‘User-Agent’, ‘不明’)

print(f”[DEBUG] 受信したReferer: {referer_url}”)
print(f”[DEBUG] ユーザーエージェント: {user_agent}”)

response = make_response({“status”: “success”, “received_referer”: referer_url})
# CORSを許可する設定（検証用）
response.headers.add(“Access-Control-Allow-Origin”, “”)
return response

if __name__ == ‘__main__’:
# ポート5000でサーバーを起動
app.run(host=’0.0.0.0′, port=5000, debug=True)

② Fetch API / JavaScript による送信制御のテスト

ブラウザ側から外部APIを叩く際、どのような `Referer` が送られるかをテストするコードです。

// 開発者ツールのコンソール等で実行して挙動を確認できます
async function testRefererSend() {
try {
// 同一オリジンまたは外部APIへのリクエスト
const response = await fetch(‘http://localhost:5000/api/track’, {
method: ‘GET’,
// mode: ‘cors’, // 必要に応じて
// 【重要】ここでRefererの送信ポリシーを明示的に制御できます
referrerPolicy: ‘no-referrer’
});

const data = await response.json();
console.log(‘サーバーからの応答:’, data);
} catch (error) {
console.error(‘通信エラー:’, error);
}
}

testRefererSend();

—

3. Referrer-Policy によるモダンな情報漏洩防止策

かつては `` タグの `rel=”noreferrer”` などを駆使して泥臭く制御していましたが、現代のWebインフラでは `Referrer-Policy` HTTPヘッダー（またはHTMLのメタタグ）を用いて、宣言的にコントロールするのがデファクトスタンダードです。