HTTP 요청 스머글링 입문 — CL.TE·TE.CL로 캐시가 오염되는 원리 [2026]

HTTP 요청 스머글링은 프론트엔드(프록시·CDN)와 백엔드 서버가 한 요청의 경계를 다르게 해석해, 공격자가 뒤 요청에 몰래 요청을 끼워 넣는 취약점이다.
요청 경계가 어긋나면 다음 사용자의 요청에 악성 요청이 붙어 캐시 오염·인증 우회·자격증명 탈취로 확대되며, 프록시 계층이 많은 현대 SaaS일수록 표면이 넓다.
이 글은 자주 발생하는 실수 패턴, 표준 구현 코드, 30초 자가진단, 24시간 패치 순서를 정리했다.

한눈에 보는 핵심

자주 발생하는 실수 패턴

표준 구현 코드

# WSGI/미들웨어 방어 — 모호한 길이 헤더 요청 거부
class RejectSmugglingMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        te = request.META.get("HTTP_TRANSFER_ENCODING", "")
        cl = request.META.get("CONTENT_LENGTH", "")
        # CL과 TE 동시 존재는 모호 → 거부
        if te and cl:
            from django.http import HttpResponse
            return HttpResponse("ambiguous length", status=400)
        # chunked 외의 알 수 없는 TE 값 거부
        if te and te.strip().lower() != "chunked":
            from django.http import HttpResponse
            return HttpResponse("bad transfer-encoding", status=400)
        return self.get_response(request)
# 인프라단: 프론트·백엔드 HTTP 파서 버전·규칙 일치, 전 구간 HTTP/2 권장

핵심은 "동작하는 코드"와 "안전한 코드"가 다르다는 점이다.
AI 코딩 도구는 기능 충족 코드를 우선 출력하므로 보안 분기는 별도로 강제해야 한다.
미들웨어·정책·CI 게이트로 모든 경로에 일괄 적용하는 것이 표준이다.

30초 자가진단

# 1. CL+TE 동시 포함 요청에 서버가 400을 주는지(정상은 거부)
printf 'POST / HTTP/1.1\r\nHost: x\r\nContent-Length: 6\r\nTransfer-Encoding: chunked\r\n\r\n0\r\n\r\n' | nc yourhost 80

# 2. 프론트/백엔드 서버·프록시 버전 일치 여부 점검
#    서로 다른 파서 규칙이면 위험. 전용 도구(HTTP Request Smuggler)로 안전 테스트

위 시그널이 발견되면 결함이다. OWASP HTTP Request Smuggling를 함께 참조하라.

24시간 패치 절차

지금 해야 할 것

실무자: CodeScan 무료 스캔으로 30초 점검 후 우선순위대로 패치.
CISO·임원: 조직 전체 점검·규제 대응은 SENTRIX 30분 1:1 상담으로.
결함은 발견 즉시, 늦어도 24시간 안에 패치하는 것이 표준이다.

관련 글

• Open Redirect 피싱 악용
• CSP nonce 우회