RSS

HSTS 설정 전 알아야 할 옵션과 안전한 적용 순서

웹 인프라글: , Duolabs3분 읽기bloghstshttpsmodel-openai-gpt-5.5securitytechnical-noteweb-infra

HSTS(HTTP Strict Transport Security)는 브라우저에 “이 도메인은 항상 HTTPS로만 접속해야 한다”고 알려주는 보안 정책입니다. 잘 설정하면 중간자 공격과 SSL stripping을 줄일 수 있지만, 성급하게 적용하면 장애 복구가 어려워질 수 있습니다.

HSTS란

서버가 다음과 같은 응답 헤더를 보내면 브라우저는 일정 기간 동안 해당 도메인을 HTTP가 아닌 HTTPS로만 접속합니다.

Strict-Transport-Security: max-age=15552000; includeSubDomains

한 번 정책을 받은 브라우저는 max-age가 끝날 때까지 HTTP 접속을 자동으로 HTTPS로 바꿉니다.

핵심 옵션

max-age

HSTS 정책을 브라우저가 얼마나 오래 기억할지 정합니다.

처음부터 너무 긴 기간을 설정하면 인증서 문제나 도메인 이전 문제가 생겼을 때 복구가 어렵습니다. 운영 초기에는 짧게 시작하고 안정화 후 6개월, 12개월로 늘리는 방식이 안전합니다.

includeSubDomains

하위 도메인까지 HSTS를 적용합니다.

모든 서브도메인이 HTTPS를 안정적으로 지원한다면 켜는 것이 좋습니다. 하지만 일부 개발용 또는 레거시 서브도메인이 HTTP만 지원한다면 장애가 날 수 있으므로 먼저 정리해야 합니다.

preload

브라우저 자체 preload 목록에 도메인을 등록하는 방식입니다. 첫 방문부터 HTTPS를 강제할 수 있지만, 해제에 매우 오랜 시간이 걸립니다.

대부분의 일반 서비스나 작은 조직에서는 성급하게 켜지 않는 것이 좋습니다. 인증서 자동 갱신, 모든 서브도메인 HTTPS, 장기 운영 안정성이 충분히 검증된 뒤에만 검토해야 합니다.

nosniff

X-Content-Type-Options: nosniff는 브라우저가 MIME 타입을 임의로 추측하지 못하게 합니다. HSTS와 별개지만 함께 켜는 경우가 많고, 일반적으로 부작용이 적습니다.

안전한 적용 순서

  1. 모든 페이지가 HTTPS로 정상 동작하는지 확인
  2. 인증서 자동 갱신이 안정적인지 확인
  3. 짧은 max-age로 테스트
  4. 문제가 없으면 6개월 수준으로 확장
  5. 모든 서브도메인이 HTTPS라면 includeSubDomains 적용
  6. preload는 장기 안정화 후 별도 검토

검증 방법

curl -sI https://example.com | grep -i strict

응답에 strict-transport-security 헤더가 보이면 적용된 것입니다.

사고가 났을 때

일반 HSTS는 max-age=0을 내려 브라우저 정책을 해제할 수 있습니다. 하지만 사용자가 새 헤더를 받아야 해제가 반영됩니다. 그래서 처음부터 긴 max-age를 설정하면 복구가 늦어질 수 있습니다.

preload는 훨씬 더 복구가 어렵습니다. 해제 신청 후 브라우저 릴리스에 반영되기까지 오래 걸릴 수 있으므로 신중해야 합니다.

듀오랩스가 보는 관점

HSTS는 “켜면 좋은 보안 옵션”이지만, 운영 안정성과 함께 봐야 합니다. 특히 여러 서브도메인을 운영하는 회사라면 전체 도메인 구조와 인증서 갱신 체계를 먼저 점검한 뒤 단계적으로 적용하는 것이 안전합니다.

함께 읽기