O artigo argumenta que o HTTP é fundamentalmente falho para comunicação de proxy reverso com backend devido a vulnerabilidades de dessincronização/contrabando de requisições e problemas de cabeçalhos não confiáveis. FastCGI, um protocolo de rede de 30 anos, resolve esses problemas de forma limpa.

Por que o HTTP é ruim para proxies reversos

Ataques de Dessincronização / Contrabando de Requisições: HTTP/1.1 não possui enquadramento explícito de mensagens — a própria mensagem descreve onde termina, com várias maneiras ambíguas de fazer isso. Parsers diferentes (proxy vs backend) podem discordar sobre os limites da mensagem, permitindo ataques. James Kettle, após encontrar outro lote no ano passado, declarou "HTTP/1.1 deve morrer". HTTP/2 corrige isso quando usado consistentemente, mas a adoção tem sido lenta: nginx só obteve suporte a backend HTTP/2 no final de 2025, e o suporte do Apache ainda é "experimental".

Cabeçalhos Não Confiáveis: Não há uma maneira robusta de um proxy passar informações confiáveis (IP do cliente, detalhes de autenticação, certificados mTLS) para o backend sem misturar com cabeçalhos controlados pelo cliente atacante. Proxies devem deletar cuidadosamente todas as instâncias de cabeçalhos como X-Real-IP antes de adicionar os seus próprios — é fácil errar. FastCGI possui canais de parâmetros separados (ex.: REMOTE_ADDR, AUTH_TYPE) que são estruturalmente distintos dos dados da requisição.

FastCGI: Um Protocolo de Rede, Não um Modelo de Processo

FastCGI pode ser usado como HTTP — enviar requisições via sockets TCP/UNIX para um daemon de longa duração. Em Go, a mudança é trivial:
import "net/http/fcgi"
Substitua http.Serve(l, handler) por fcgi.Serve(l, handler). Seu handler ainda usa os padrões http.ResponseWriter e http.Request.

Exemplos de Configuração 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

Proxies populares como Apache, Caddy, nginx e HAProxy todos suportam backends FastCGI com mudanças simples de configuração.

Conclusão Principal

FastCGI possui enquadramento explícito de mensagens desde 1996 (um cabeçalho simples com comprimento do conteúdo, sem ambiguidade) e canais de parâmetros confiáveis separados. Mudar de HTTP para FastCGI entre proxy e backend elimina uma classe inteira de vulnerabilidades sem sacrificar funcionalidade.