L'article soutient que HTTP est fondamentalement défectueux pour la communication proxy inverse vers le backend en raison des vulnérabilités de désynchronisation / de détournement de requête et des problèmes d'en-têtes non fiables. FastCGI, un protocole filaire vieux de 30 ans, résout ces problèmes proprement.

Pourquoi HTTP est nul pour les proxys inverses

Attaques de désynchronisation / Détournement de requêtes : HTTP/1.1 manque de cadrage explicite des messages — le message lui-même décrit où il se termine, avec plusieurs façons ambiguës de le faire. Différents analyseurs (proxy vs backend) peuvent être en désaccord sur les limites des messages, permettant des attaques. James Kettle, après avoir trouvé un autre lot l'année dernière, a déclaré « HTTP/1.1 doit mourir ». HTTP/2 corrige cela lorsqu'il est utilisé de manière cohérente, mais l'adoption a été lente : nginx n'a obtenu le support HTTP/2 backend qu'à la fin de 2025, et le support d'Apache est toujours « expérimental ».

En-têtes non fiables : Il n'existe aucun moyen robuste pour un proxy de transmettre des informations fiables (IP client, détails d'authentification, certificats mTLS) au backend sans les mélanger avec des en-têtes clients contrôlés par l'attaquant. Les proxys doivent soigneusement supprimer toutes les instances d'en-têtes comme X-Real-IP avant d'ajouter les leurs — facile à se tromper. FastCGI dispose de canaux de paramètres séparés (par exemple, REMOTE_ADDR, AUTH_TYPE) qui sont structurellement distincts des données de requête.

FastCGI : Un protocole filaire, pas un modèle de processus

FastCGI peut être utilisé comme HTTP — envoyer des requêtes via des sockets TCP/UNIX à un démon à long terme. En Go, basculer est trivial :
import "net/http/fcgi"
Remplacez http.Serve(l, handler) par fcgi.Serve(l, handler). Votre gestionnaire utilise toujours les http.ResponseWriter et http.Request standard.

Exemples de configuration de proxy

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

Les proxys populaires comme Apache, Caddy, nginx et HAProxy supportent tous les backends FastCGI avec des modifications de configuration simples.

Point clé à retenir

FastCGI a un cadrage explicite des messages depuis 1996 (en-tête simple avec longueur de contenu, aucune ambiguïté) et des canaux de paramètres de confiance séparés. Passer de HTTP à FastCGI entre le proxy et le backend élimine toute une classe de vulnérabilités sans sacrifier la fonctionnalité.