HSTS 설정 전 알아야 할 옵션과 안전한 적용 순서
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와 별개지만 함께 켜는 경우가 많고, 일반적으로 부작용이 적습니다.
안전한 적용 순서
- 모든 페이지가 HTTPS로 정상 동작하는지 확인
- 인증서 자동 갱신이 안정적인지 확인
- 짧은
max-age로 테스트 - 문제가 없으면 6개월 수준으로 확장
- 모든 서브도메인이 HTTPS라면
includeSubDomains적용 - preload는 장기 안정화 후 별도 검토
검증 방법
curl -sI https://example.com | grep -i strict
응답에 strict-transport-security 헤더가 보이면 적용된 것입니다.
사고가 났을 때
일반 HSTS는 max-age=0을 내려 브라우저 정책을 해제할 수 있습니다. 하지만 사용자가 새 헤더를 받아야 해제가 반영됩니다. 그래서 처음부터 긴 max-age를 설정하면 복구가 늦어질 수 있습니다.
preload는 훨씬 더 복구가 어렵습니다. 해제 신청 후 브라우저 릴리스에 반영되기까지 오래 걸릴 수 있으므로 신중해야 합니다.
듀오랩스가 보는 관점
HSTS는 “켜면 좋은 보안 옵션”이지만, 운영 안정성과 함께 봐야 합니다. 특히 여러 서브도메인을 운영하는 회사라면 전체 도메인 구조와 인증서 갱신 체계를 먼저 점검한 뒤 단계적으로 적용하는 것이 안전합니다.