Host

사용법

모든 HTTP/1.1 요청에는 Host 헤더가 포함됩니다. 이 헤더는 하나의 IP 주소를 가진 단일 서버가 여러 도메인을 호스팅하는 가상 호스팅을 가능하게 합니다. Host가 없으면 서버는 클라이언트가 어떤 도메인에 접근하려 했는지 판단할 방법이 없습니다.

값은 요청한 호스트명과 콜론으로 구분된 선택적 포트 번호를 담습니다. 포트를 지정하지 않으면 해당 스킴의 기본 포트가 적용됩니다. HTTP는 80번, HTTPS는 443번 포트입니다.

Host 헤더 없이 HTTP/1.1 요청을 받은 서버는 400 Bad Request로 응답합니다. 요청에 Host 헤더가 둘 이상 들어 있을 때도 마찬가지인데, 모호함 때문에 서버가 올바른 가상 호스트를 선택할 수 없기 때문입니다.

HTTP/2와 HTTP/3에서는 :authority 의사 헤더 필드가 Host를 대체합니다. HTTP/2나 HTTP/3 요청을 보내는 클라이언트는 호스트 정보를 대신 :authority에 담습니다. 게이트웨이가 HTTP/2 요청을 HTTP/1.1로 변환할 때는 :authority 값으로부터 Host 헤더를 생성합니다.

Host 헤더는 Origin 헤더와 다릅니다. Host는 모든 요청에서 대상 서버를 식별합니다. Origin은 교차 출처 요청의 출처를 식별하며 CORS 사전 요청이나 폼 제출 같은 특정 맥락에서만 나타납니다.

host

대상 서버의 도메인 이름 또는 IP 주소입니다.

port

선택적인 TCP 포트 번호입니다. 생략되면 요청 스킴의 기본 포트(HTTP는 80, HTTPS는 443)로 간주됩니다.

Host: <host>:<port>

예시

웹 서버로 보내는 표준 HTTPS 요청입니다. 443이 HTTPS의 기본 포트이므로 포트를 생략했습니다.

GET /articles/http-headers HTTP/1.1
Host: example.re

서버가 비표준 포트에서 실행 중이면 호스트명 뒤에 포트 번호를 덧붙입니다.

GET /api/status HTTP/1.1
Host: api.example.re:8443

IP 주소로 보내는 요청은 주소를 직접 담습니다. 이 형태는 개발 환경과 내부 서비스에서 흔합니다.

GET /health HTTP/1.1
Host: 192.168.1.100:3000

보안

Host 헤더 인젝션은 애플리케이션이 값을 먼저 검증하지 않고 Host 값을 사용해 URL(비밀번호 재설정 링크, 정규 URL, 리다이렉트)을 생성할 때 발생합니다. 공격자가 위조된 Host 값으로 요청을 보내면, 애플리케이션은 공격자가 통제하는 도메인을 가리키는 링크를 만들어 냅니다.

Host 헤더를 예상되는 값의 화이트리스트와 대조해 검증하십시오. nginx에서는 server_name을 정의하고, 인식되지 않는 요청을 받아 444를 반환하는 기본 catch-all 서버 블록을 두십시오. Django에서는 ALLOWED_HOSTS를 허용 도메인 목록으로 설정하십시오. Rails에서는 애플리케이션 환경에서 host_authorization을 구성하십시오. 브라우저는 Host를 금지된 요청 헤더로 취급하여 클라이언트 측 JavaScript가 값을 바꾸지 못하게 막지만, 서버 간 요청이나 curl 같은 도구에는 그런 제약이 없습니다.