이 글에서는 HTTP가 역직렬화/요청 밀반입 취약점과 신뢰할 수 없는 헤더 문제로 인해 리버스 프록시-백엔드 통신에 근본적으로 부적합하다고 주장합니다. 30년 된 와이어 프로토콜인 FastCGI는 이러한 문제를 깔끔하게 해결합니다.

리버스 프록시에 HTTP가 안 좋은 이유

역직렬화 공격 / 요청 밀반입: 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로 전환하면 기능 손실 없이 취약점 클래스 전체를 제거할 수 있습니다.