HSTS가 SEO에 영향을 주나요?

직접적으로는 아닙니다 — HSTS라는 순위 요소는 없습니다. HTTPS 자체가 약한 순위 신호이고, 오히려 간접 효과가 큽니다. 혼합 콘텐츠 경고가 사라지고, 첫 방문마다 붙던 리다이렉트 한 번이 없어지고, 방문자를 쫓아내는 브라우저 경고 화면이 뜨지 않습니다.

잘못 설정했으면 어떻게 되돌리나요?

`max-age=0`을 내려보내고 기다리는 수밖에 없습니다. 다시 방문한 브라우저는 항목을 지우지만, 저장된 max-age가 만료되기 전에 재방문하지 않은 사용자는 계속 HTTPS로 묶여 있습니다. 원격으로 강제할 방법이 없습니다 — 천천히 올려야 한다는 주장의 근거가 바로 이겁니다.

'헤더를 확인할 수 없음'이라고 나옵니다

페이지를 렌더링 방식으로만 읽을 수 있어서 원본 응답 헤더를 관찰하지 못했다는 뜻입니다. 이 경우 헤더 검사는 '실패'가 아니라 '해당 없음'으로 표시되고, 0점이 아니라 점수 계산에서 제외됩니다.

HSTS만 있으면 충분한가요?

아닙니다. 전송 구간만 보장합니다. XSS, 클릭재킹, MIME 스니핑은 각각 CSP, 프레임 보호, nosniff가 담당합니다. HSTS는 가장 먼저 넣을 헤더이지 마지막 헤더가 아닙니다.

HSTS 설정 확인 · 보안 헤더 검사

HSTS는 브라우저에게 '이 도메인은 앞으로 평문 HTTP로 접속하지 말라'고 지시하는 헤더입니다. 리다이렉트가 일어나기 전, 신뢰할 수 없는 네트워크에서 첫 요청이 가로채일 수 있는 틈을 닫아줍니다. 도메인을 입력하면 실제 응답 헤더를 읽어 HSTS와 함께 실제 공격을 막아주는 나머지 헤더들도 보고해 드립니다.

35%가 HSTS 헤더 없음

분석한 웹사이트 959개 기준

공개 데이터베이스의 전체 사이트를 대상으로 집계했습니다.

왜 중요한가

리다이렉트와 HSTS는 다릅니다

HTTP를 HTTPS로 리다이렉트해도, 맨 처음 요청은 이미 평문으로 기기를 떠난 뒤입니다. 적대적인 네트워크에서는 그 요청이 가로채여, 서버의 리다이렉트가 도착하기도 전에 응답이 위조될 수 있습니다 — 전형적인 SSL 스트리핑 공격입니다. HSTS는 브라우저가 아무것도 보내기 전에 스스로 주소를 HTTPS로 바꿔 쓰게 만들어 그 틈을 닫습니다.

동시에 잘못 넣으면 가장 위험한 헤더이기도 합니다

HSTS는 기간이 붙은 약속입니다. 브라우저가 `max-age=31536000`을 한 번 본 순간부터 1년간 그 도메인에 평문 HTTP 접속을 거부하고, 이미 방문자 기기에 저장된 그 약속을 원격으로 취소할 방법은 없습니다. 인증서가 만료되거나 HTTPS 준비가 안 된 서브도메인이 있으면, 해당 사용자는 '무시하고 접속' 버튼도 없는 오류 화면을 보게 됩니다. max-age를 1년부터 시작하지 말고 단계적으로 올려야 하는 이유입니다.

고치는 방법

1. HTTPS부터 완전히 정상화하세요
적용 대상이 될 모든 서브도메인이 유효한 인증서를 갖고 HTTPS로 제대로 응답해야 하며, 내부 링크와 리소스도 이미 https여야 합니다. 이전이 덜 끝난 사이트에 HSTS를 얹으면 '경고'가 '접속 불가'로 바뀝니다.
2. max-age를 단계적으로 올리세요
`Strict-Transport-Security: max-age=300`으로 시작해 아무것도 깨지지 않는지 확인하고, 86400(하루) → 2592000(한 달) → 31536000(1년) 순으로 올립니다. 각 단계를 되돌릴 수 있는 건 오직 직전 구간이 짧았기 때문입니다.
3. includeSubDomains는 정말 그럴 때만
`includeSubDomains`는 아직 만들지도 않은 서브도메인과, 나중에 누군가 http로만 띄울 내부 도구까지 전부 포함합니다. 최종적으로는 맞는 설정이지만, 성급하게 넣었다가 자기 스테이징 환경에 못 들어가게 되는 게 가장 흔한 사고입니다.
4. preload는 영구 조치로 간주하세요
브라우저 preload 목록에 제출하면 크롬·파이어폭스·사파리·엣지 빌드 자체에 도메인이 박힙니다. 빼는 데는 몇 달이 걸립니다. 전체 헤더(`max-age=31536000; includeSubDomains; preload`)를 충분히 오래 무리 없이 돌린 뒤에만 하세요.
5. 설정 파일 연 김에 나머지도 같이
`X-Content-Type-Options: nosniff`, `Referrer-Policy: strict-origin-when-cross-origin`, 프레임 보호(`X-Frame-Options: SAMEORIGIN` 또는 CSP `frame-ancestors`) 세 줄은 호환성 위험이 없습니다. 진짜 까다로운 건 CSP인데, `Content-Security-Policy-Report-Only`로 먼저 돌려 리포트를 읽어본 뒤 적용하세요.

설명 말고, 그냥 고쳐드릴까요?

이 항목은 서버 설정 영역이라 호스팅형 플랫폼에서는 저희가 직접 손댈 수 없습니다. 그래서 할 수 있다고 하지 않습니다. 고정가 작업에 포함되는 건, 호스팅사나 개발자가 그대로 적용할 수 있게 정리한 설정 지시서입니다.

고정가 보기 →

자주 묻는 질문

HSTS가 SEO에 영향을 주나요?: 직접적으로는 아닙니다 — HSTS라는 순위 요소는 없습니다. HTTPS 자체가 약한 순위 신호이고, 오히려 간접 효과가 큽니다. 혼합 콘텐츠 경고가 사라지고, 첫 방문마다 붙던 리다이렉트 한 번이 없어지고, 방문자를 쫓아내는 브라우저 경고 화면이 뜨지 않습니다.
잘못 설정했으면 어떻게 되돌리나요?: `max-age=0`을 내려보내고 기다리는 수밖에 없습니다. 다시 방문한 브라우저는 항목을 지우지만, 저장된 max-age가 만료되기 전에 재방문하지 않은 사용자는 계속 HTTPS로 묶여 있습니다. 원격으로 강제할 방법이 없습니다 — 천천히 올려야 한다는 주장의 근거가 바로 이겁니다.
'헤더를 확인할 수 없음'이라고 나옵니다: 페이지를 렌더링 방식으로만 읽을 수 있어서 원본 응답 헤더를 관찰하지 못했다는 뜻입니다. 이 경우 헤더 검사는 '실패'가 아니라 '해당 없음'으로 표시되고, 0점이 아니라 점수 계산에서 제외됩니다.
HSTS만 있으면 충분한가요?: 아닙니다. 전송 구간만 보장합니다. XSS, 클릭재킹, MIME 스니핑은 각각 CSP, 프레임 보호, nosniff가 담당합니다. HSTS는 가장 먼저 넣을 헤더이지 마지막 헤더가 아닙니다.