HTTPS 강제와 보안 헤더, HSTS 등 기본 헤더 5가지 점검법
HTTPS 강제와 보안 헤더 설정은 HTTP 접속을 HTTPS로 넘기는 리디렉션에 HSTS 헤더를 더하고, 형식 추측 차단·프레임 제한·리퍼러 정책·콘텐츠 보안 정책 헤더를 차례로 적용하는 것입니다. MDN 문서를 바탕으로 헤더 5가지의 역할과 적용 순서, 확인 방법을 정리했습니다.
HTTPS 강제가 필요한 이유
SSL 인증서를 설치해도 방문자가 주소창에 http로 시작하는 주소를 입력하거나 예전 링크를 누르면 처음 요청은 암호화되지 않은 채로 갑니다. 그래서 대부분의 사이트는 HTTP로 들어온 요청을 HTTPS 주소로 넘기는 리디렉션을 설정합니다.
MDN 문서는 리디렉션만으로는 첫 HTTP 요청 단계의 중간자 공격을 완전히 막지 못한다고 설명합니다. 이를 보완하는 것이 HSTS(Strict-Transport-Security) 헤더입니다. 인증서 갱신이 끊기면 HTTPS 자체가 깨지므로, 먼저 SSL 인증서 만료와 자동 갱신 상태를 확인해 두세요.
HSTS 헤더가 하는 일
MDN Strict-Transport-Security 문서에 따르면 브라우저는 HTTPS로 받은 이 헤더를 기억해 두었다가, 이후 그 사이트에 HTTP로 접속하려 하면 자동으로 HTTPS로 바꿔 요청합니다. 기억하는 기간은 max-age 값(초 단위)으로 정하고, includeSubDomains를 붙이면 모든 하위 도메인에 같은 규칙이 적용됩니다.
같은 문서는 HTTP로만 접속되는 사이트에서 보낸 HSTS 헤더는 브라우저가 무시하며, 인증서 오류 없이 HTTPS로 접속했을 때만 적용된다고 설명합니다. preload 지시어는 브라우저에 미리 등록되는 목록에 참여하겠다는 뜻인데, 명세의 일부가 아니며 등록하려면 max-age가 1년 이상이고 includeSubDomains가 있어야 합니다. includeSubDomains와 preload는 모든 하위 도메인이 HTTPS를 지원하는지 확인한 뒤에만 붙이는 것이 안전합니다.
기본 보안 헤더 5가지 비교
아래 표는 홈페이지에 먼저 검토할 보안 헤더 다섯 가지가 각각 무엇을 하는지와 적용할 때 주의할 점을 MDN 문서 내용을 기준으로 비교한 것입니다.
| 헤더 | 하는 일 | 적용할 때 주의할 점 |
|---|---|---|
| Strict-Transport-Security | 브라우저가 정해진 기간 동안 HTTPS로만 접속하게 함 | HTTPS가 완전히 준비된 뒤 적용하고, 하위 도메인 포함 여부를 확인 |
| X-Content-Type-Options | nosniff 값으로 브라우저가 파일 형식을 추측하지 않고 서버가 알린 형식을 따르게 함 | 스크립트·스타일 파일의 형식이 맞지 않으면 차단되므로 서버의 형식 설정을 확인 |
| X-Frame-Options | DENY 또는 SAMEORIGIN으로 다른 사이트가 우리 페이지를 프레임 안에 넣는 것을 제한 | 더 세밀한 설정은 콘텐츠 보안 정책의 frame-ancestors로 할 수 있음 |
| Referrer-Policy | 다른 사이트로 이동할 때 이전 페이지 주소를 얼마나 보낼지 정함 | 지정하지 않으면 기본값 strict-origin-when-cross-origin이 적용됨 |
| Content-Security-Policy | 페이지가 불러올 수 있는 스크립트와 자원을 제한해 XSS 피해를 줄임 | 인라인 스크립트 등이 막혀 화면이 깨질 수 있어 보고 전용 모드로 먼저 시험 |
각 헤더에 쓸 수 있는 값과 자세한 동작은 MDN의 X-Content-Type-Options, X-Frame-Options, Referrer-Policy 문서에서 확인할 수 있습니다.
콘텐츠 보안 정책은 보고 전용으로 시작합니다
MDN 콘텐츠 보안 정책(CSP) 안내는 정책을 바로 강제하지 말고 Content-Security-Policy-Report-Only 헤더로 위반 사항만 보고받으며 시험한 뒤 적용하라고 권합니다. 정책을 걸면 페이지 안에 직접 쓴 스크립트와 일부 기능이 멈출 수 있고, 외부 분석 도구나 지도, 채팅 위젯이 많을수록 정리할 항목이 늘어납니다. 같은 안내는 CSP가 입력값 검증을 대신하지 않는다는 점도 짚습니다. 운영자 관점의 XSS 예방은 XSS 크로스사이트 스크립팅 예방에서 다룹니다.
보안 헤더 적용 순서
헤더는 웹 서버 설정, 호스팅 관리 화면, 홈페이지 프로그램, CDN 가운데 한 곳에서 추가합니다. 어디서 설정하든 아래 순서로 하나씩 적용하고 확인하면 사이트가 깨지는 일을 줄일 수 있습니다.
- HTTPS 상태 확인: 모든 페이지와 이미지·스크립트가 HTTPS로 불러와지는지, 인증서가 자동 갱신되는지 확인합니다.
- HTTP→HTTPS 리디렉션: HTTP로 들어온 요청이 같은 주소의 HTTPS로 넘어가는지 확인합니다.
- HSTS 적용: 처음에는 짧은 기간으로 시작하고, 문제가 없으면 기간을 늘리는 방식이 관리하기 쉽습니다.
- 간단한 헤더 추가: X-Content-Type-Options, X-Frame-Options, Referrer-Policy를 추가하고 주요 화면을 확인합니다.
- CSP 보고 전용 시험: 보고 전용 헤더로 위반 보고를 모아 필요한 자원을 정리합니다.
- CSP 적용과 재확인: 정리한 정책을 적용하고 문의 폼, 지도, 분석 도구 등이 정상 작동하는지 확인합니다.
그림처럼 CSP는 가장 마지막에 둡니다. 다른 헤더는 대부분 바로 적용해도 화면 변화가 적지만, CSP는 사이트에서 쓰는 외부 자원을 모두 파악해야 하기 때문입니다.
보안 헤더 적용 확인 체크리스트
헤더가 제대로 붙었는지는 브라우저 개발자 도구의 네트워크 탭에서 페이지 응답 헤더를 열어 확인할 수 있습니다. Google Search Console의 URL 검사 도구에서도 페이지의 HTTP 응답 헤더를 볼 수 있습니다.
- http로 시작하는 주소를 입력하면 HTTPS 주소로 넘어간다.
- 응답 헤더에 Strict-Transport-Security가 있고 max-age 값이 의도한 기간이다.
- X-Content-Type-Options, X-Frame-Options, Referrer-Policy가 모든 페이지에 붙어 있다.
- CSP를 적용한 뒤 문의 폼, 지도, 동영상, 분석 도구가 정상 작동한다.
- 하위 도메인을 포함했다면 모든 하위 도메인이 HTTPS로 열린다.
체크리스트 항목은 사이트를 고치거나 서버를 옮긴 뒤에 다시 확인하는 것이 좋습니다. 서버 이전이나 CDN 설정 변경 과정에서 헤더 설정이 빠지는 경우가 있기 때문입니다.
디코랩이 돕는 방식
디코랩은 운영 중인 사이트의 유지보수와 개선, 웹 기술 컨설팅을 맡고 있습니다. 보안 헤더처럼 서버와 홈페이지 프로그램을 함께 봐야 하는 설정은 사이트 환경을 확인한 뒤 범위와 방식을 상담 후 제안합니다. 제공 서비스는 디코랩 서비스 소개에서 볼 수 있습니다.
자주 묻는 질문
SSL 인증서만 설치하면 HTTPS가 강제되나요?
인증서를 설치해도 HTTP 주소로 접속하는 길은 남아 있습니다. HTTP 요청을 HTTPS로 넘기는 리디렉션과 HSTS 헤더를 함께 설정해야 합니다.
HSTS를 적용했다가 문제가 생기면 끌 수 있나요?
MDN 문서에 따르면 max-age를 0으로 보내면 HSTS를 해제할 수 있습니다. 다만 브라우저가 새 헤더를 받기 전까지는 이전 설정이 남아 있으므로 처음에는 짧은 기간으로 시작하는 것이 안전합니다.
X-Frame-Options와 frame-ancestors 중 무엇을 써야 하나요?
MDN 문서는 더 세밀한 설정이 필요하면 CSP의 frame-ancestors를 쓰라고 안내합니다. 두 가지를 함께 보낸다면 허용 범위가 서로 같도록 맞춰 두세요.
보안 헤더를 넣으면 검색 순위가 오르나요?
보안 헤더는 방문자를 보호하기 위한 설정이며 검색 순위를 위한 장치로 보기는 어렵습니다. 다만 HTTPS 접속이 안정되면 방문자가 보안 경고를 보는 일을 줄일 수 있습니다.
우리 사이트의 응답 헤더가 어떻게 설정되어 있는지 확인하고 싶다면 사이트 주소를 적어 디코랩 프로젝트 문의로 보내 주세요.
댓글0
댓글 작성 권한이 없습니다