프록시 뒤 서비스가 X-Forwarded-For로 사용자 IP를 판단합니다. 클라이언트가 헤더를 직접 넣으면 어떻게 되나요?

전달 헤더는 신뢰하는 프록시가 어떻게 정리·추가했는지 확인한 경우에만 클라이언트 주소의 근거로 사용해야 합니다. 인터넷에서 온 헤더를 그대로 믿으면 IP 제한·감사·접근 정책을 우회할 수 있습니다.

동작 원리와 전제

경계 프록시는 외부가 보낸 전달 헤더를 제거하거나 명확한 규칙으로 재작성하고 앱은 신뢰한 hop 범위를 기준으로 해석합니다. 항상 맨 왼쪽이나 오른쪽을 택하는 규칙은 프록시 체인과 배치가 바뀌면 틀릴 수 있습니다.

선택과 실패 처리

앱에 직접 접속 가능한 경로가 있으면 프록시 검증을 우회할 수 있으므로 네트워크 접근도 제한합니다. X-Forwarded-Proto·Host를 HTTPS 판단이나 링크 생성에 사용할 때도 같은 신뢰 경계가 필요합니다. 표준 Forwarded 사용 자체가 신뢰성을 보장하지는 않습니다.

구체적인 사례와 검증

프록시가 기존 X-Forwarded-For 뒤에 주소를 추가하는 구성에서는 외부가 넣은 첫 주소가 그대로 남을 수 있습니다. 앱이 첫 주소를 무조건 사용자 IP로 믿으면 제한을 우회할 수 있습니다. 신뢰된 프록시 목록과 hop 처리 규칙을 한곳에서 관리하고 새 프록시 추가 시 회귀 테스트를 수행합니다. 직접 backend에 접근한 요청에는 전달 헤더를 신뢰하지 않거나 경로 자체를 차단합니다. 로드밸런서와 앱 로그에 각각 실제 peer와 해석된 client를 남기면 프록시 체인 오류를 찾기 쉽습니다. 다만 IP 자체도 개인정보일 수 있으므로 보존 기간과 접근권한을 제한합니다.

직접 접속·중첩 프록시·위조 헤더·IPv6·중복 필드를 시험합니다. IP는 사용자 신원을 완전히 나타내지 않고 NAT·VPN도 있어 인증·인가를 대체하지 않습니다. 로그에는 해석한 주소와 경로를 구분하되 개인정보 보존 정책을 적용합니다.