HSTS란 무엇인가 — max-age·includeSubDomains·preload 한 번에 정리

1. HSTS란 무엇인지 먼저 이해하기

1) 왜 HSTS설정이 자주 검색되는가

웹사이트를 운영하다 보면 “분명 HTTPS를 적용했는데도 왜 보안 점검이 필요할까?”라는 질문이 생기곤 합니다. 이때 많이 확인하는 항목이 바로 HSTS설정입니다. HSTS는 브라우저가 사이트에 접속할 때 HTTPS만 사용하도록 강제하는 기능으로, 단순히 인증서를 설치하는 것과는 조금 다른 의미를 가집니다.
특히 사용자는 주소창에 http://로 들어가도 자동으로 안전한 연결로 넘어가길 기대하는 경우가 많아, HTTPS강제가 제대로 되어 있는지 확인하려고 검색하게 됩니다.
이 글에서는 HSTS의 기본 개념부터 max-age, includeSubDomains, preload까지 핵심만 차례대로 정리해 보겠습니다. 또한 실제로 어떤 상황에서 도움이 되는지, 그리고 점검할 때 무엇을 주의해야 하는지도 함께 살펴보겠습니다.

2) HSTS의 핵심 역할

HSTS는 Strict-Transport-Security 헤더를 통해 브라우저에 “이 사이트는 앞으로 HTTPS로만 접속하라”라고 알려주는 방식입니다. 한 번 정책이 적용되면 이후 사용자가 실수로 HTTP로 접속해도 브라우저가 자동으로 HTTPS로 전환하는 구조입니다.
이 기능은 중간에서 평문 HTTP 요청이 섞이는 상황을 줄여 주기 때문에, 로그인이나 결제처럼 민감한 흐름이 있는 사이트에서 특히 중요하게 다뤄집니다.
즉, HSTS는 단순한 권장 설정이 아니라, 사용자의 접속 경로 자체를 안전하게 유도하는 보안 장치에 가깝습니다.

3) 보안헤더와 함께 보는 이유

HSTS는 단독으로 보기도 하지만, 보통은 다른 보안헤더와 함께 점검하는 편입니다. 예를 들어 X-Frame-Options, Content-Security-Policy, X-Content-Type-Options 같은 헤더와 함께 설정 상태를 확인하면 웹사이트의 기본 방어 수준을 더 넓게 볼 수 있습니다.
특히 Vibe Guardian처럼 URL만 입력해 기본 보안 상태를 빠르게 확인하는 도구를 활용하면, 이런 보안헤더 누락 여부를 한 번에 살펴보는 데 도움이 됩니다. 복잡한 보안 솔루션을 바로 도입하기 전에 “기본부터 제대로 되어 있는지” 확인하는 용도로 적합한 편입니다.

2. HSTS설정이 실제로 하는 일

1) HTTP 접속을 HTTPS로 유도하는 방식

HSTS설정의 가장 큰 목적은 HTTPS강제입니다. 사용자가 실수로 http://example.com으로 들어가더라도, 브라우저가 이전에 HSTS 정책을 기억하고 있다면 자동으로 https://example.com으로 연결합니다.
이 때문에 첫 연결이 이미 HTTPS여야 의미가 있으며, 사이트가 아예 HTTPS를 제공하지 않는다면 HSTS는 적용할 수 없습니다.
운영자 입장에서는 “HTTPS로만 서비스하고 있다”는 사실을 브라우저에 명확히 전달하는 셈입니다.

2) 중간자 공격과 평문 노출 위험 줄이기

HTTP는 초기 접속 단계에서 평문 요청이 섞일 수 있어, 공격자가 연결을 가로채거나 사용자를 잘못된 주소로 유도하는 위험이 있습니다. HSTS는 이런 위험을 완화하는 데 도움을 줍니다.
특히 로그인 페이지, 회원가입 페이지, 관리자 페이지처럼 민감한 기능이 있는 웹사이트일수록 HSTS설정 여부가 중요하게 다뤄집니다.
물론 HSTS만으로 모든 보안 문제가 해결되는 것은 아니지만, 최소한의 기본 보안 상태를 정리하는 데에는 핵심적인 역할을 합니다.

3) 사용자 경험 측면의 장점

보안 관점뿐 아니라 사용자 경험 측면에서도 HSTS는 의미가 있습니다. 매번 HTTP와 HTTPS 사이를 오가며 리다이렉트를 처리하는 대신, 브라우저가 한 번 학습한 뒤 바로 안전한 경로로 접속하기 때문입니다.
다만 운영자가 설정을 잘못하면 예기치 않은 접속 오류가 생길 수 있어, 적용 전 점검이 필요합니다.
이 때문에 많은 팀이 배포 전에 HSTS설정과 다른 보안헤더를 함께 확인하는 절차를 두는 경우가 많습니다.

3. max-age는 무엇을 의미할까

1) 정책 유지 기간을 정하는 값

HSTS의 핵심 지시문 중 하나가 max-age입니다. 이는 브라우저가 해당 도메인에 대해 HTTPS 정책을 얼마나 오래 기억할지 정하는 값입니다.
예를 들어 max-age=31536000은 약 1년 동안 브라우저가 HSTS 정책을 유지한다는 뜻입니다. 값이 길수록 HTTPS강제가 오래 유지되지만, 설정 실수가 있을 때 회복하기가 더 까다로울 수 있습니다.
반대로 너무 짧으면 실질적인 보호 효과가 약해질 수 있습니다.

2) 처음에는 짧게, 이후 늘리는 경우가 많음

실무에서는 처음부터 긴 기간으로 두기보다 짧은 기간으로 시작해 문제 없는지 확인한 뒤 점차 늘리는 방식이 자주 사용됩니다.
이 방식은 인증서 갱신, 서브도메인 구조, 리다이렉트 흐름이 안정적인지 확인하는 데 도움이 됩니다.
즉, max-age는 단순히 큰 숫자를 넣는 문제가 아니라, 운영 환경에 맞춰 조심스럽게 설정해야 하는 값입니다.

3) 설정 오류 시 주의할 점

만약 HTTPS 인증서가 만료되었거나, 일부 페이지에서 HTTPS가 제대로 동작하지 않는데도 긴 max-age를 설정하면 접속 장애가 길어질 수 있습니다.
그래서 HSTS설정은 “켜면 끝”이 아니라, 인증서 관리와 배포 구조를 함께 봐야 합니다.
기본 보안 상태를 빠르게 점검하는 도구를 활용하면, 인증서와 헤더 설정이 현재 정상인지 먼저 확인하는 데 도움이 됩니다.

4. includeSubDomains는 왜 중요한가

1) 하위 도메인까지 적용하는 옵션

includeSubDomains는 HSTS 정책을 주 도메인뿐 아니라 하위 도메인에도 적용하는 옵션입니다. 예를 들어 example.com에 이 옵션이 포함되면 shop.example.com, admin.example.com 같은 하위 도메인도 HTTPS로만 접속해야 합니다.
이 설정은 전체 서비스가 이미 HTTPS 체계로 정리되어 있을 때 유용합니다.
반대로 일부 하위 도메인이 아직 HTTPS를 지원하지 않으면 접속 문제가 생길 수 있습니다.

2) 구조가 복잡한 사이트일수록 더 신중해야 함

조직 내부 시스템, 구형 서비스, 테스트용 서브도메인이 섞여 있는 환경에서는 includeSubDomains를 바로 적용하면 곤란해질 수 있습니다.
이 옵션은 강력한 만큼 영향 범위도 넓기 때문에, 사용 중인 도메인 구조를 먼저 파악해야 합니다.
특히 오랫동안 운영된 사이트라면 “겉으로는 메인 도메인만 보이지만 실제로는 여러 하위 도메인이 쓰이고 있는지” 확인하는 과정이 필요합니다.

3) 안전한 적용을 위한 체크포인트

includeSubDomains를 적용하기 전에 확인할 항목은 다음과 같습니다.

• 모든 하위 도메인이 HTTPS를 지원하는지
• 인증서 범위가 충분한지
• 리다이렉트 규칙이 충돌하지 않는지
• 오래된 서비스나 테스트 주소가 남아 있지 않은지

이런 점검을 먼저 해두면, HSTS설정을 더 안정적으로 운영할 수 있습니다.
기본적인 보안 상태를 검사하는 도구를 활용하면, 예상보다 많은 하위 경로가 노출되어 있거나 보안헤더가 일부 빠져 있는지도 함께 확인하기 좋습니다.

5. preload는 무엇이며 HSTSPreload와 어떤 관계가 있을까

1) 브라우저에 사전 등록되는 방식

preload는 HSTS를 브라우저가 미리 알고 있도록 하는 개념입니다. 일반 HSTS는 사용자가 사이트에 한 번 방문해야 정책이 저장되지만, HSTSPreload는 브라우저가 시작부터 해당 도메인을 HTTPS 전용 목록으로 인식할 수 있게 합니다.
즉, 첫 방문부터 HTTP 연결을 차단하는 효과를 기대할 수 있습니다.
이 때문에 보안 관점에서는 매우 강력한 옵션으로 여겨집니다.

2) HSTSPreload는 신중하게 결정해야 함

HSTSPreload는 편리해 보이지만, 한 번 등록하면 되돌리기까지 시간이 걸릴 수 있습니다.
또한 메인 도메인뿐 아니라 모든 하위 도메인이 HTTPS를 완전히 지원해야 하고, 설정 요건도 비교적 엄격한 편입니다.
그래서 충분한 운영 안정성이 확보된 사이트에서만 고려하는 것이 일반적입니다.

3) preload를 고려하기 전에 필요한 조건

보통 다음 조건을 먼저 확인합니다.

• 메인 도메인과 하위 도메인이 모두 HTTPS 지원
• max-age가 충분히 길게 설정됨
• includeSubDomains가 포함됨
• HTTP에서 HTTPS로 안정적으로 이동 가능
• 인증서 관리 체계가 안정적임

이 조건이 맞지 않으면 HSTSPreload는 오히려 운영 리스크가 될 수 있습니다.
따라서 무조건 적용하기보다, 현재 사이트의 보안 구성 수준을 먼저 점검한 뒤 판단하는 것이 좋습니다.

6. HSTS설정 점검 시 함께 보면 좋은 항목

1) HTTPS와 인증서 상태

HSTS는 HTTPS가 정상 동작해야 의미가 있으므로, 먼저 인증서가 유효한지 확인해야 합니다. 만료된 인증서가 있으면 사용자는 오히려 접속 경고를 보게 됩니다.
또한 중간 인증서 체인 문제, 도메인 불일치, 리다이렉트 오류도 함께 확인하는 편이 좋습니다.
HSTS설정만 보고 안심하기보다, 실제 접속이 끝까지 문제없이 되는지 보는 것이 중요합니다.

2) 보안헤더 전반의 균형

HSTS는 여러 보안헤더 중 하나입니다. 사이트의 목적에 따라 CSP, Referrer-Policy, X-Frame-Options 같은 헤더도 함께 고려하면 좋습니다.
특히 외부 스크립트가 많은 사이트는 브라우저 보안 정책과 충돌이 생길 수 있어, 헤더를 하나씩 확인하는 과정이 필요합니다.
기본 보안은 개별 설정보다 전체 조합이 더 중요하게 작용하는 경우가 많습니다.

3) 실제 브라우저 동작 확인

단순히 서버 설정만 보고 끝내기보다, 브라우저에서 Mixed Content 경고가 뜨는지, 쿠키가 안전하게 전달되는지, API 호출에 문제가 없는지 보는 것이 좋습니다.
Vibe Guardian처럼 URL 입력만으로 기본 보안 상태를 빠르게 점검하는 도구는 이런 초반 확인에 유용한 편입니다.
복잡한 침투 테스트를 대체하는 것은 아니지만, “기본이 빠져 있는지”를 빠르게 찾는 데는 충분히 도움이 됩니다.

7. 어떤 경우에 HSTS설정을 고려하면 좋을까

1) 로그인이나 결제 기능이 있는 서비스

사용자 계정 정보, 세션 쿠키, 결제 관련 데이터가 오가는 사이트라면 HSTS설정을 우선적으로 검토하는 경우가 많습니다.
이런 서비스는 작은 접속 실수도 보안 문제로 이어질 수 있기 때문입니다.
특히 HTTPS로 이미 전환을 마친 상태라면, HTTPS강제를 명확히 해 두는 것이 운영 안정성에 도움이 됩니다.

2) 하위 도메인이 정리된 조직 사이트

메인 사이트와 하위 도메인들이 비교적 체계적으로 관리되고 있다면 includeSubDomains까지 검토할 수 있습니다.
이 경우 HSTS는 개별 페이지 수준의 설정이 아니라 도메인 전체의 기본 규칙처럼 작동합니다.
단, 서브도메인 구조가 복잡하다면 먼저 점검을 충분히 해보는 편이 안전합니다.

3) 보안 설정을 기본부터 정리하고 싶은 경우

고가의 복잡한 보안 도구를 바로 도입하기 전에, 우선 사이트의 기본 보안 상태를 확인하고 싶은 경우가 있습니다.
이때 HSTS설정, 인증서 상태, 보안헤더, 쿠키 속성, API 접근 구조를 한 번에 훑어보는 방식이 실용적입니다.
Vibe Guardian처럼 URL 기반으로 빠르게 점검하는 도구는 이런 상황에서 기본기 확인용으로 활용할 수 있습니다.

마지막으로 정리하면, HSTS설정은 HTTPS를 제대로 쓰고 있는 사이트에서 접속 경로를 더 안전하게 고정해 주는 장치입니다. max-age는 유지 기간, includeSubDomains는 하위 도메인 적용 범위, preload는 브라우저 사전 등록과 연결되는 개념으로 이해하면 됩니다. 다만 HSTS는 한 번 설정하면 영향 범위가 넓기 때문에, 인증서와 보안헤더 상태를 함께 확인한 뒤 적용하는 것이 좋습니다. 직접 전화로 문의해 하나씩 확인하는 방식과 달리, 기본 점검 도구를 활용하면 현재 설정 상태를 빠르게 훑어보고 문제 지점을 먼저 찾을 수 있다는 차이가 있습니다. 이런 점에서 HSTS설정은 HTTPS 전환을 마쳤거나, 사이트의 기본 보안을 체계적으로 정리하고 싶은 경우에 고려해 볼 만합니다.