Der Artikel argumentiert, dass HTTP aufgrund von Desync-/Request-Smuggling-Schwachstellen und Problemen mit nicht vertrauenswürdigen Headern grundsätzlich ungeeignet für die Kommunikation zwischen Reverse-Proxy und Backend ist. FastCGI, ein 30 Jahre altes Drahtprotokoll, löst diese Probleme sauber.

Warum HTTP für Reverse-Proxies schlecht ist

Desync-Angriffe / Request-Smuggling: HTTP/1.1 fehlt explizites Nachrichten-Framing – die Nachricht selbst beschreibt, wo sie endet, und zwar auf mehrere mehrdeutige Arten. Verschiedene Parser (Proxy vs. Backend) können unterschiedliche Nachrichtengrenzen ermitteln, was Angriffe ermöglicht. James Kettle erklärte nach einer weiteren Fundserie im letzten Jahr: „HTTP/1.1 muss sterben“. HTTP/2 behebt dies bei konsistenter Nutzung, aber die Einführung ist langsam: nginx erhielt HTTP/2-Backend-Unterstützung erst Ende 2025, und die Unterstützung von Apache ist noch „experimentell“.

Nicht vertrauenswürdige Header: Es gibt keine robuste Möglichkeit für einen Proxy, vertrauenswürdige Informationen (Client-IP, Authentifizierungsdetails, mTLS-Zertifikate) an das Backend zu übergeben, ohne dass diese mit vom Angreifer kontrollierten Client-Headern vermischt werden. Proxies müssen sorgfältig alle Instanzen von Headern wie X-Real-IP löschen, bevor sie ihre eigenen hinzufügen – das kann leicht schiefgehen. FastCGI hat separate Parameterkanäle (z. B. REMOTE_ADDR, AUTH_TYPE), die strukturell von den Anfragedaten getrennt sind.

FastCGI: Ein Drahtprotokoll, kein Prozessmodell

FastCGI kann wie HTTP verwendet werden – sendet Anfragen über TCP/UNIX-Sockets an einen langlebigen Daemon. In Go ist der Wechsel trivial:
import "net/http/fcgi"
Ersetzen Sie http.Serve(l, handler) durch fcgi.Serve(l, handler). Ihr Handler verwendet weiterhin die Standard-http.ResponseWriter und http.Request.

Beispiele für Proxy-Konfigurationen

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

Beliebte Proxies wie Apache, Caddy, nginx und HAProxy unterstützen alle FastCGI-Backends mit einfachen Konfigurationsänderungen.

Wichtigste Erkenntnis

FastCGI hat seit 1996 explizites Nachrichten-Framing (einfacher Header mit Inhaltslänge, keine Mehrdeutigkeit) und getrennte vertrauenswürdige Parameterkanäle. Der Wechsel von HTTP zu FastCGI zwischen Proxy und Backend eliminiert eine ganze Klasse von Schwachstellen, ohne die Funktionalität zu beeinträchtigen.