FastCGI：30年経った今もリバースプロキシに最適なプロトコル

Apr 29, 2026 · security web · Source ↗

要約

FastCGIは30年前のワイヤープロトコルだが、デザイン上の理由からHTTPリバースプロキシにおけるデシンク攻撃やヘッダーインジェクションといったセキュリティ上の落とし穴を回避できる。

HTTP/1.1のデシンク（リクエストスマグリング）は構造的な欠陥だ。明示的なメッセージフレーミングがないため、プロキシとバックエンドがメッセージ境界を異なって解釈することがある。これにより、最近発覚したDiscordメディアプロキシ脆弱性のような攻撃が成立してしまう。
FastCGIはすべてのクライアントヘッダーに HTTP_ というプレフィックスを付与するため、攻撃者が REMOTE_ADDR や X-Real-IP などの信頼されたプロキシデータと誤認されるヘッダーを注入することが構造上不可能になっている。
Goへの移行は最小限の作業で済む。net/http/fcgi を使って http.Serve を fcgi.Serve に差し替えるだけだ。nginx、Caddy、Apache、HAProxy はいずれも1行の設定変更でFastCGIバックエンドをサポートする。
HTTP/2はデシンクを解決するが、ヘッダー信頼の分離は解決しない。また、nginxがHTTP/2バックエンドをサポートしたのは2025年末のことで、Apacheのサポートはいまだ実験的段階だ。
FastCGIはWebSocketをサポートしておらず、ベンチマークではいくらかスループットの低下が見られる。これはプロトコルのオーバーヘッドではなく、最適化が不十分なコードパスに起因するとされている。