X-Forwarded-Forを信頼してはいけないケース（誤判定・事故を防ぐ判断基準）

URLをコピーしました！

ロードバランサ（LB）配下のHTTP/HTTPS構成で、

「クライアントIPはX-Forwarded-Forを見ればいい」

と説明されることは非常に多いです。

しかし実務では、

IP制限がすり抜ける
ログのIPが信用できない
攻撃元を誤認する

といった事故が、X-Forwarded-For（以下XFF）の

「過信」

によって発生します。

本記事では、

XFFが「何を保証しないか」
信頼してはいけない具体ケース
その場でできる確認方法
正しい解決・代替策

を丁寧に解説します。

まず結論：X-Forwarded-Forは「自己申告」

最初に最重要ポイントです。

X-Forwarded-Forは“認証情報”ではありません。

HTTPヘッダであり、

書き換え可能
付与されている保証がない

という前提で扱う必要があります。

X-Forwarded-Forとは何か（簡単に）

XFFは、LBやプロキシが

「元のクライアントIPを伝えるために付け足すヘッダ」

です。

X-Forwarded-For: 203.0.113.10

ただし、

HTTPクライアント自身が自由に書ける

点が重要です。

信頼してはいけないケース①：インターネットから直接到達する

LBやプロキシを経由せず、

直接サーバにHTTPアクセスできる構成

では、XFFは信頼できません。

理由

クライアントが任意のXFFを送れる
サーバ側では真偽を判定できない

判断基準

サーバの80/443が直接公開されている

解決方法

LB以外からのHTTPアクセスを遮断
信頼できる送信元IPを限定

信頼してはいけないケース②：XFFを上書きせず追記している

XFFは、

複数IPをカンマ区切りで持てる

仕様です。

X-Forwarded-For: 1.1.1.1, 2.2.2.2

先頭が本当のクライアントとは限りません。

判断基準

LBがXFFを「append」している

解決方法

LBでXFFを必ず上書きする
信頼するIPの範囲を明示

信頼してはいけないケース③：多段プロキシ構成

以下のような構成では、

Client → CDN → LB → Proxy → Server

XFFは

「どこまでが信頼できるか」

を整理しないと意味を失います。

よくある事故

CDNのIPを誤ってクライアント扱い
内部プロキシIPで上書き

解決方法

trusted proxy を明確に定義
real_ip_recursive の理解

信頼してはいけないケース④：IP制限・セキュリティ用途

XFFを使って、

管理画面アクセス制御
FW代替のIP制限

を行うのは非常に危険です。

理由

HTTPヘッダは偽装可能
信頼境界を越えてくる

判断基準

XFFを条件に allow/deny している

解決方法

L3/L4（FW・SG）で制御
Proxy Protocolの利用検討

今すぐできる確認方法

tcpdumpでヘッダ確認

tcpdump -A port 80 | grep X-Forwarded-For

想定外の値が来ていないか確認します。

ログのIPと実通信の一致確認

アクセスログのIP
tcpdumpの送信元IP

が一致しない場合、信頼できません。

X-Forwarded-Forを使ってよい条件まとめ

LB/Proxy以外から直接アクセス不可
XFFを上書きしている
信頼境界が明確
ログ用途・分析用途に限定

これを満たさない場合、

XFFは参考情報に留めるべき

です。

まとめ（判断基準を一文で）

X-Forwarded-Forは「信頼できる経路からのみ届くと保証できる場合」に限り使う。

それ以外では、

「見えているから使う」は事故の元

になります。

XFFは便利ですが、

セキュリティ境界を超えさせてはいけません。