Strict-Transport-Security 설정 기준 정리

본문 중간의 쿠팡 추천 상품 구매시 쿠팡 파트너스에서 일정액의 수수료를 제공받습니다.

Strict-Transport-Security 설정 기준 정리

Strict-Transport-Security는 브라우저가 특정 호스트를 앞으로는 HTTPS로만 접속하도록 기억하게 만드는 응답 헤더다. 2026년 6월 12일 기준 MDN 문서는 이 헤더가 이후의 HTTP 접속 시도를 자동으로 HTTPS로 올리고, 인증서 오류가 나면 사용자가 경고를 무시하고 진행할 수 없게 만든다고 설명한다.

실무에서 자주 헷갈리는 지점은 세 가지다. max-age를 얼마로 둘지, includeSubDomains를 바로 켜도 되는지, 그리고 HSTS preload까지 등록해야 하는지다. 이 글은 RFC 6797, MDN, HSTS preload 공식 안내를 기준으로 선택 기준만 정리한다.

HSTS는 무엇을 보호할까?

RFC 6797은 HSTS를 통해 사용자 에이전트가 해당 호스트에 대해 안전하지 않은 전송을 사용하지 않도록 강제할 수 있다고 정의한다. 핵심은 사용자가 한 번이라도 HTTPS 응답에서 HSTS 헤더를 받으면, 다음부터는 같은 호스트에 대한 HTTP URL을 브라우저가 HTTPS로 바꿔 요청한다는 점이다.

MDN은 여기에 더해 HSTS 호스트에서 TLS 인증서 오류가 발생하면 브라우저가 우회 수단을 제공하지 않는다고 설명한다. 따라서 HSTS는 단순 리디렉션보다 강한 정책이다.

헤더 값은 어떻게 구성할까?

지시어	의미	실무 기준
max-age	브라우저가 HSTS 정책을 기억할 기간(초)	운영 안정성이 확인되기 전에는 짧게 시작하고, 장기 적용이 가능하면 늘린다.
includeSubDomains	하위 도메인에도 동일 정책 적용	모든 서브도메인이 HTTPS를 안정적으로 제공할 때만 켠다.
preload	브라우저 preload 목록 제출용 선언	사전 로딩 요건을 장기적으로 만족할 수 있을 때만 검토한다.

MDN 문서의 문법 예시는 max-age만 단독으로 쓰거나, 여기에 includeSubDomains와 preload를 붙이는 형태다. 또한 MDN은 preload를 사용할 때 max-age가 최소 31536000초(1년)여야 하고 includeSubDomains가 함께 있어야 한다고 안내한다.

대부분의 서비스에서 먼저 볼 기준은?

첫 번째 기준은 HTTPS 운영 안정성이다. MDN에 따르면 HSTS는 인증서 오류가 나도 예외 진행이 불가능하므로, 인증서 자동 갱신과 체인 구성, 서브도메인 TLS 상태가 안정적이어야 한다.

두 번째 기준은 서브도메인 범위다. RFC 6797과 MDN 모두 includeSubDomains가 하위 도메인 전체에 영향을 준다고 설명한다. 개발용, 내부용, 오래된 서브도메인 중 HTTP만 쓰는 것이 하나라도 있으면 이 옵션은 바로 적용하기 어렵다.

세 번째 기준은 롤백 난이도다. MDN은 HSTS 해제를 위해 max-age=0을 HTTPS 응답으로 다시 보내야 하며, 누락한다고 바로 해제되지 않는다고 설명한다. 즉 잘못 길게 잡은 값은 브라우저에 남아 있기 때문에 초기에는 짧은 기간으로 검증하는 편이 안전하다.

HTTP 리디렉션만 있으면 충분할까?

아니다. MDN은 HSTS를 모르는 첫 HTTP 요청은 여전히 네트워크 공격에 노출될 수 있다고 설명한다. 사용자가 처음 http://example.com으로 접속하면, 브라우저는 아직 그 호스트를 HSTS 호스트로 모르기 때문이다.

이 때문에 HSTS는 HTTP에서 HTTPS로 보내는 301 리디렉션을 대체하는 것이 아니라, 그 다음 요청부터 더 강하게 보호하는 보완 수단으로 이해하는 편이 정확하다.

 

 

preload는 언제 검토할까?

MDN은 preload가 HSTS 명세 자체의 일부는 아니며, Google이 운영하는 별도 preload 서비스라고 설명한다. 대신 preload에 들어가면 브라우저가 첫 방문 전부터 해당 도메인을 HTTPS 전용으로 취급할 수 있어, 최초 요청 취약점을 줄이는 데 도움이 된다.

2026년 6월 12일 기준 hstspreload.org는 제출 요건으로 유효한 인증서, HTTP에서 HTTPS로의 동일 호스트 리디렉션, 모든 서브도메인의 HTTPS 제공, 그리고 base domain의 HTTPS 응답에 max-age=31536000, includeSubDomains, preload가 포함된 HSTS 헤더를 요구한다.

이 요건을 보면 preload는 "한번 써 보고 아니면 되돌리는" 설정에 가깝지 않다. 특히 내부 서브도메인까지 HTTPS 대상에 포함된다는 점이 중요하다. 따라서 preload는 모든 서브도메인을 장기적으로 HTTPS로 유지할 수 있을 때만 검토하는 편이 맞다.

권장 적용 순서는?

1. 기본 HTTPS 운영과 인증서 자동 갱신이 안정적인지 먼저 확인한다.
2. 초기에는 비교적 짧은 max-age로 적용해 운영 이슈가 없는지 본다.
3. 모든 서브도메인이 HTTPS만 쓰는 것이 확인되면 includeSubDomains를 검토한다.
4. 최초 요청 보호가 꼭 필요하고 preload 요건을 장기적으로 지킬 수 있을 때만 preload 제출을 검토한다.

자주 묻는 질문

Q. HSTS 헤더를 HTTP 응답에 넣어도 될까?

안 된다. MDN은 브라우저가 HTTP로 전달된 HSTS 헤더를 무시한다고 설명한다. HSTS 헤더는 HTTPS 응답으로만 보내야 한다.

Q. IP 주소에도 HSTS를 적용할 수 있을까?

MDN은 HSTS 호스트가 도메인 이름으로만 식별되며 IP 주소는 HSTS 호스트가 될 수 없다고 설명한다. 따라서 운영 기준도 도메인 단위로 잡아야 한다.

Q. includeSubDomains를 켜면 부모 도메인과 자식 도메인이 같은 방식으로 저장될까?

MDN 설명에 따르면 브라우저는 각 도메인과 서브도메인의 HSTS 정책을 독립적으로 저장할 수 있다. 다만 상위 도메인 정책에 includeSubDomains가 있으면 하위 도메인에도 보호 효과가 이어질 수 있다.

FAQ

Q. 무난한 시작점은 무엇일까?

모든 서브도메인이 이미 HTTPS로 안정적이라면 max-age=31536000; includeSubDomains가 자주 쓰이는 운영값이다. 다만 새로 도입하는 서비스라면 짧은 max-age로 먼저 검증하는 절차가 더 안전하다.

Q. preload까지 바로 가는 것이 항상 좋을까?

그렇지 않다. preload는 최초 요청 보호에는 유리하지만, 내부 서브도메인까지 HTTPS 유지 의무가 생긴다. 운영 범위를 장기적으로 책임질 수 있을 때만 선택해야 한다.

Q. 리디렉션이 있으면 HSTS 없이도 충분할까?

첫 요청 관점에서는 충분하지 않다. 사용자가 처음 HTTP로 들어오는 순간은 리디렉션 전에 노출될 수 있기 때문에, HSTS는 그 약점을 줄이기 위한 추가 정책으로 봐야 한다.

정리

HSTS는 HTTPS 리디렉션을 예쁘게 만드는 헤더가 아니라, 브라우저가 이후 요청을 HTTPS로 강제하고 인증서 오류 우회를 막도록 하는 보안 정책이다. 선택 기준은 HTTPS 운영 안정성, 모든 서브도메인의 HTTPS 준비 상태, 그리고 롤백 부담이다.

대부분의 서비스에서는 preload부터 시작하기보다 HSTS 자체를 안정적으로 적용하는 것이 먼저다. 특히 includeSubDomains와 preload는 범위가 넓기 때문에, 서브도메인 전체 운영 상태를 확인한 뒤 적용하는 편이 안전하다.

참고 자료

• RFC 6797: HTTP Strict Transport Security (HSTS)
• MDN Web Docs: Strict-Transport-Security header
• HSTS Preload List Submission