El artículo argumenta que HTTP es fundamentalmente defectuoso para la comunicación de proxy inverso a backend debido a vulnerabilidades de desincronización/contrabando de solicitudes y problemas de cabeceras no confiables. FastCGI, un protocolo de cable de 30 años, resuelve estos problemas de manera limpia.

Por qué HTTP apesta para los proxies inversos

Ataques de desincronización/contrabando de solicitudes: HTTP/1.1 carece de un encuadre de mensajes explícito: el mensaje mismo describe dónde termina, con múltiples formas ambiguas de hacerlo. Diferentes analizadores (proxy vs backend) pueden discrepar sobre los límites del mensaje, permitiendo ataques. James Kettle, después de encontrar otro lote el año pasado, declaró que "HTTP/1.1 debe morir". HTTP/2 soluciona esto cuando se usa de manera consistente, pero la adopción ha sido lenta: nginx solo obtuvo soporte backend HTTP/2 a fines de 2025, y el soporte de Apache sigue siendo "experimental".

Cabeceras no confiables: No hay una forma robusta para que un proxy pase información confiable (IP del cliente, detalles de autenticación, certificados mTLS) al backend sin mezclarse con cabeceras de cliente controladas por atacantes. Los proxies deben eliminar cuidadosamente todas las instancias de cabeceras como X-Real-IP antes de agregar las suyas propias, lo que es fácil de equivocar. FastCGI tiene canales de parámetros separados (por ejemplo, REMOTE_ADDR, AUTH_TYPE) que son estructuralmente distintos de los datos de la solicitud.

FastCGI: un protocolo de cable, no un modelo de proceso

FastCGI se puede usar como HTTP: enviar solicitudes a través de sockets TCP/UNIX a un daemon de larga duración. En Go, el cambio es trivial:
import "net/http/fcgi"
Reemplace http.Serve(l, handler) con fcgi.Serve(l, handler). Su manejador aún usa http.ResponseWriter y http.Request estándar.

Ejemplos de configuración 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

Los proxies populares como Apache, Caddy, nginx y HAProxy soportan backends FastCGI con cambios de configuración simples.

Conclusión clave

FastCGI ha tenido un encuadre de mensajes explícito desde 1996 (un encabezado simple con longitud de contenido, sin ambigüedad) y canales de parámetros confiables separados. Cambiar de HTTP a FastCGI entre el proxy y el backend elimina una clase completa de vulnerabilidades sin sacrificar funcionalidad.