この記事では、HTTPがリバースプロキシからバックエンドへの通信において、desync/リクエストスマグリングの脆弱性や信頼できないヘッダの問題から、根本的に欠陥があると論じています。30年前のワイヤープロトコルであるFastCGIは、これらの問題をクリーンに解決します。

リバースプロキシにHTTPが不向きな理由

Desync攻撃/リクエストスマグリング: HTTP/1.1には明示的なメッセージフレーミングがなく、メッセージ自体がその終端を示す方法が複数あり曖昧です。プロキシとバックエンドで異なるパーサーがメッセージ境界を異なる解釈をすることで、攻撃が可能になります。James Kettle氏は昨年新たなバッチを発見した後、「HTTP/1.1は死ななければならない」と宣言しました。HTTP/2は一貫して使用すればこの問題を修正しますが、普及は遅く、nginxは2025年後半にようやくHTTP/2バックエンドをサポートし、Apacheのサポートはまだ「実験的」です。

信頼できないヘッダ: プロキシがクライアントのIPや認証情報、mTLS証明書などの信頼できる情報を、攻撃者が制御するクライアントヘッダと混ざらずにバックエンドに渡す確実な方法がありません。プロキシは独自のヘッダを追加する前に、X-Real-IPなどのヘッダのインスタンスをすべて慎重に削除する必要があり、間違いが起こりやすいです。FastCGIには、リクエストデータとは構造的に異なる別個のパラメータチャネル（例：REMOTE_ADDR、AUTH_TYPE）があります。

FastCGI：プロセスモデルではなく、ワイヤープロトコル

FastCGIはHTTPのように使用でき、TCP/UNIXソケットを介して常時実行デーモンにリクエストを送信します。Goでは、切り替えは簡単です：
import "net/http/fcgi"
http.Serve(l, handler) を fcgi.Serve(l, handler) に置き換えるだけです。ハンドラは標準の http.ResponseWriter と http.Request を引き続き使用できます。

プロキシ設定例

nginx:

# HTTP
proxy_pass http://localhost:8080;

FastCGI
fastcgi_pass localhost:8080;
include fastcgi_params;

Apache:

# HTTP
ProxyPass / http://localhost:8080/

FastCGI
ProxyPass / fcgi://localhost:8080/

Caddy:

# HTTP
reverse_proxy localhost:8080 {
    transport http { }
}

FastCGI
reverse_proxy localhost:8080 {
    transport fastcgi { }
}

HAProxy:

# HTTP
backend app_backend
    server s1 localhost:8080

FastCGI
fcgi-app fcgi_app
    docroot /
backend app_backend
    use-fcgi-app fcgi_app
    server s1 localhost:8080 proto fcgi

Apache、Caddy、nginx、HAProxyなどの人気プロキシは、シンプルな設定変更でFastCGIバックエンドをサポートしています。

重要なポイント

FastCGIは1996年以来、明示的なメッセージフレーミング（単純なヘッダとコンテンツ長で曖昧さなし）と、別個の信頼できるパラメータチャネルを備えています。プロキシとバックエンド間でHTTPからFastCGIに切り替えることで、機能を犠牲にすることなく、脆弱性のクラス全体を排除できます。