HTTP 리버스 프록시의 보안 함정, 30년 된 프로토콜이 해답인 이유 (agwa.name)

한줄 요약

리버스 프록시 구조에서 HTTP를 그대로 쓰는 건 보안 사고를 예약하는 것이다.

리버스 프록시와 백엔드 서버 간 통신 프로토콜 선택은 성능보다 보안에 더 큰 영향을 미친다. 에이전시 입장에서 클라이언트 서비스를 설계할 때, 이 레이어를 HTTP로 퉁치는 관행은 운영 중 예상치 못한 취약점을 남긴다.

HTTP를 프록시 내부 통신에 쓰면 왜 위험한가

많은 프로젝트에서 nginx나 Apache 앞단에 프록시를 두고, 프록시에서 백엔드로도 그냥 HTTP를 쓴다. 외부 통신과 내부 통신에 동일한 프로토콜을 사용하니 설정이 간단하고 익숙하다. 문제는 HTTP/1.1이 구조적으로 메시지 경계가 불명확하다는 점이다.

HTTP/1.1 메시지는 명시적인 프레이밍 없이 메시지 스스로 자신의 끝을 기술한다. Content-Length와 Transfer-Encoding이 충돌하거나, 대소문자·공백 처리 방식이 구현체마다 달라지면 프록시와 백엔드가 메시지 경계를 다르게 해석할 수 있다. 이게 HTTP 디싱크(Desync) 공격, 즉 요청 스머글링의 근본 원인이다.

쉽게 말하면, 프록시는 요청 A가 끝났다고 보는데 백엔드는 아직 요청 A가 진행 중이라고 본다. 그 틈으로 공격자의 악의적인 데이터가 다른 사용자의 요청인 척 처리된다. 이 종류의 취약점은 패치로 완전히 막기 어렵다. 구현체가 바뀔 때마다 새로운 경계 불일치가 등장하기 때문이다.

헤더 신뢰 문제: 프록시가 추가한 정보를 백엔드가 검증할 방법이 없다

디싱크만이 문제가 아니다. HTTP 구조상 프록시가 백엔드에 신뢰 정보를 전달할 표준적인 방법이 없다. 실제 클라이언트 IP, 인증된 사용자 정보, mTLS 클라이언트 인증서 내용 같은 것들을 전달하려면 X-Real-IP, X-Forwarded-For 같은 커스텀 헤더를 쓸 수밖에 없다.

문제는 이 헤더들이 클라이언트가 임의로 보내는 헤더와 구조적으로 구분되지 않는다는 것이다. 프록시가 들어오는 요청에서 해당 헤더를 삭제하고 자신의 값을 넣는 방식으로 방어하지만, 이 삭제 로직이 완전하지 않으면 공격자가 위조한 헤더를 신뢰 정보로 착각하게 된다. 대소문자 변형, 헤더 중복, 미들웨어가 사용하는 추가적인 헤더 종류까지 모두 처리해야 하는데, 이걸 실수 없이 구현하는 건 생각보다 훨씬 어렵다.

외주 개발 프로젝트에서는 특히 위험하다. 프레임워크나 미들웨어가 어떤 헤더를 신뢰하는지 모두 파악하지 못한 채 배포되는 경우가 많기 때문이다.

FastCGI는 이 두 문제를 구조적으로 해결한다

FastCGI는 1996년에 설계된 프로토콜이지만, 리버스 프록시 내부 통신에서 발생하는 현대적 보안 문제 두 가지를 모두 구조적으로 해결한다.

첫째, 메시지 프레이밍이 명확하다. FastCGI는 고정 길이 헤더를 가진 바이너리 레코드 단위로 통신한다. 메시지 경계가 프로토콜 수준에서 명시적으로 정의되므로 구현체 간 해석 차이가 생길 여지가 없다. HTTP/2가 해결한 문제를 FastCGI는 30년 전에 이미 해결했다.

둘째, 신뢰 정보와 클라이언트 헤더가 구조적으로 분리된다. FastCGI는 클라이언트가 보낸 HTTP 헤더를 백엔드에 전달할 때 HTTP_ 접두사를 붙인다. Content-Type은 HTTP_CONTENT_TYPE이 되는 식이다. 반면 프록시가 추가하는 신뢰 정보(REMOTE_ADDR, SERVER_NAME 등)는 접두사 없이 별도 파라미터로 전달된다. 클라이언트가 아무리 헤더를 조작해도 신뢰 파라미터 영역을 침범할 수 없다. 구조 자체가 위조를 불가능하게 만든다.

Go 기준으로 코드 변경은 단 한 줄이다. http.Serve 대신 표준 라이브러리의 fcgi.Serve를 쓰면 핸들러 코드는 그대로 유지된다. nginx, Apache, Caddy 같은 주요 프록시들은 FastCGI 백엔드를 이미 지원하고 있다.

에이전시 실무에서 FastCGI 도입 시 고려할 점

FastCGI가 모든 상황의 정답은 아니다. 몇 가지 현실적인 제약을 알고 선택해야 한다.

WebSocket을 사용하는 프로젝트에는 적용할 수 없다. FastCGI 명세가 WebSocket이 등장하기 전에 작성됐고, 이후 업데이트가 없었기 때문이다. 채팅, 실시간 대시보드, 알림 시스템 등 WebSocket 의존도가 높은 서비스라면 해당 구간은 HTTP/2를 유지해야 한다.

디버깅 도구 지원도 약하다. HTTP 기반 API는 curl이나 Postman으로 바로 테스트할 수 있지만, FastCGI는 전용 도구가 필요하다. 개발·테스트 단계에서 팀 전체가 이를 인지하고 있어야 운영 중 혼선을 줄일 수 있다.

성능 면에서는 일부 워크로드에서 HTTP/1.1보다 처리량이 낮게 측정되기도 한다. 이는 프로토콜의 구조적 한계라기보다 HTTP 대비 최적화가 덜 된 구현체의 문제에 가깝다. 대부분의 비즈니스 워크로드에서는 차이를 체감하기 어렵다.