회사 홈페이지에 HTTPS를 적용했다면 HSTS 헤더도 바로 켜야 할까요?

HSTS는 브라우저가 회사 홈페이지를 일정 기간 HTTPS로만 접속하도록 기억하게 하는 응답 헤더이므로, 하위 도메인과 인증서 상태를 먼저 점검한 뒤 적용하는 편이 안전합니다. 한 번 켜면 방문자의 브라우저에 설정이 남기 때문에 서버 설정 하나를 바꾸는 것보다 영향이 오래갑니다.

HSTS가 브라우저에 남기는 약속을 이해하세요

MDN의 Strict-Transport-Security 문서는 이 헤더가 해당 호스트에 HTTPS로만 접속해야 하며, 이후 HTTP로 접속하려는 시도는 자동으로 HTTPS로 바뀌어야 한다고 브라우저에 알린다고 설명합니다. 또 이후 연결에서 인증서가 잘못된 경우 같은 보안 연결 오류가 나도 브라우저가 사용자에게 무시하고 들어가는 선택지를 주지 않는다고 적고 있습니다.

같은 문서에 따르면 이 헤더는 HTTPS 응답으로 보낼 때만 효력이 있고, HTTP로 보내면 브라우저가 무시합니다. HTTP 요청을 받는 서버는 301 같은 영구 이동으로 https 주소를 안내하되, 그 이동 응답에는 HSTS 헤더를 넣지 않아야 한다고 설명합니다.

하위 도메인과 인증서를 먼저 점검하세요

MDN은 includeSubDomains 지시어를 쓰면 HSTS 정책이 그 도메인의 모든 하위 도메인에도 적용된다고 설명합니다. 회사 대표 주소 외에 채용 안내, 관리자 화면, 예전 행사용 주소처럼 따로 운영하는 하위 도메인이 있다면 모두 HTTPS와 유효한 인증서를 갖추었는지 먼저 확인해야 합니다. MDN의 예시 설명도 이런 설정이 HTTP로만 제공되는 페이지나 하위 도메인으로의 접근을 막는다고 적고 있어, 준비가 덜 된 주소는 방문자에게 열리지 않을 수 있습니다.

AI로 생성한 개념 이미지. 실제 사업장 사진이 아닙니다. 닫힌 문은 HTTPS와 인증서 준비가 안 된 주소에 방문자가 들어갈 수 없는 상황을 비유한 것으로, HSTS의 실제 동작 화면이 아닙니다.

탱탱소프트의 운영 권장은 개발 담당자와 운영 담당자가 함께 하위 도메인 목록을 만들고, 주소마다 HTTPS 응답과 인증서 만료일, 담당자를 적어 두는 것입니다. MDN은 브라우저가 상위 도메인보다 하위 도메인에 먼저 접속할 수 있으므로 각 하위 도메인도 자체 응답에 헤더를 보내는 편이 좋다고 안내합니다. 예를 들어 링크가 모두 www 주소로 연결된다면 www 주소에서도 헤더를 보내야 합니다.

AI로 생성한 개념 이미지. 실제 사업장 사진이 아닙니다.

유지 기간과 되돌리는 방법도 정해 두세요

MDN에 따르면 브라우저는 헤더를 받을 때마다 max-age만큼 만료 시각을 다시 늘리고, 이후 응답에서 헤더가 빠져도 이전 설정은 만료될 때까지 유지됩니다. HSTS를 끄려면 max-age=0을 보내야 하는데, 이것도 브라우저가 HTTPS로 다시 접속해 응답을 받아야 반영됩니다. 또 주요 브라우저가 쓰는 사전 등록 목록에 올리는 preload를 함께 쓰려면 max-age가 1년(31536000초) 이상이고 includeSubDomains가 있어야 한다고 설명합니다.

그래서 탱탱소프트는 짧은 유지 기간으로 먼저 적용해 하위 도메인과 외부 연동에 문제가 없는지 확인한 뒤 기간을 늘리는 방식을 권합니다. 적용 뒤에는 브라우저 개발자 도구에서 응답 헤더를 확인하고, http 주소로 접속했을 때 https로 이동하는지 함께 살펴보세요. 청주·충북 기업을 포함한 일반적인 운영 점검이며, 실제 값은 호스팅과 서비스 구성에 따라 달라집니다.

참고 자료

• MDN Web Docs, Strict-Transport-Security header