보안 헤더 점검

보안 헤더 점검은 웹사이트가 응답에 내려보내는 HSTS·CSP·X-Frame-Options·X-Content-Type-Options·Referrer-Policy·Permissions-Policy 여섯 가지 핵심 보안 헤더의 적용 여부를 실시간으로 확인하는 도구입니다. 이들 헤더는 중간자 공격, 클릭재킹, MIME 스니핑, 정보 유출 같은 흔한 웹 위협을 브라우저 차원에서 막아 주므로, 적용 여부만 점검해도 사이트의 기본 방어 수준을 빠르게 가늠할 수 있습니다.

URL만 입력하면 서버가 해당 주소로 안전하게 요청을 보내 응답 헤더를 읽고, 적용된 헤더 개수로 점수와 등급(A~F)을 매깁니다. 본문은 내려받지 않고 헤더만 확인하므로 빠르고 가볍습니다. 결과는 잠시 캐싱되어 반복 점검 시 즉시 응답합니다.

점검하는 보안 헤더의 역할

• Strict-Transport-Security (HSTS): 이후 접속을 항상 HTTPS로 강제해 다운그레이드·중간자 공격을 차단합니다.
• Content-Security-Policy (CSP): 허용된 출처의 스크립트·스타일·이미지만 로드하게 해 XSS와 데이터 주입을 줄입니다.
• X-Frame-Options: 페이지를 다른 사이트의 프레임에 끼워 넣지 못하게 해 클릭재킹을 방지합니다.
• X-Content-Type-Options: nosniff 값으로 브라우저의 MIME 타입 추측을 막아 잘못된 실행을 방지합니다.
• Referrer-Policy: 외부로 전송되는 리퍼러 정보의 범위를 제한해 URL에 담긴 민감정보 유출을 줄입니다.
• Permissions-Policy: 카메라·마이크·위치 등 브라우저 기능 사용 권한을 명시적으로 제한합니다.

점수와 등급 읽는 법

점수는 여섯 개 헤더 중 적용된 개수(n/6)로 계산하며, 비율에 따라 A부터 F까지 등급을 부여합니다. 모든 헤더가 적용되면 A, 절반 이하면 D 이하로 떨어집니다. 다만 단순 존재 여부만 확인하므로, CSP 정책이 너무 느슨하거나 HSTS의 max-age가 짧은 경우처럼 값의 품질까지 보장하지는 않습니다. 표에서 각 헤더의 실제 값을 함께 확인해 설정이 의도대로 들어갔는지 검토하세요.

적용 후 다시 점검하기

헤더는 웹서버(nginx·Apache)나 애플리케이션·CDN 설정에서 추가합니다. 변경 후에는 캐시·CDN 전파 때문에 잠시 옛 응답이 보일 수 있으니, 적용 직후보다 몇 분 뒤 다시 점검하는 편이 정확합니다. CSP 헤더를 처음 만든다면 CSP 생성기로 정책을 조립하고, 쿠키 보안 속성은 쿠키 보안 점검으로 함께 확인하세요.

권장 헤더 값 빠른 참조

이 도구는 헤더의 존재 여부만 채점하지만, 실제 방어력은 값에서 나옵니다. 아래는 일반적인 사이트에 무난하게 적용할 수 있는 권장 시작값입니다(엄격한 정책일수록 동작 검증이 필요).

해석 예시 한 단계씩

예를 들어 어떤 사이트의 응답에 strict-transport-security: max-age=300, x-content-type-options: nosniff, x-frame-options: SAMEORIGIN 세 개만 있다고 합시다. 이 도구는 3/6 = C 정도로 표시합니다. 하지만 표의 실제 값을 보면 HSTS의 max-age가 고작 300초(5분)라 사실상 효과가 없고, CSP·Referrer-Policy·Permissions-Policy는 통째로 비어 있습니다. 즉 등급은 “괜찮음”처럼 보여도 가장 중요한 XSS 방어(CSP)가 없는 상태입니다. 채점 숫자보다 표의 값을 읽는 것이 핵심인 이유입니다.

흔한 실수 / 함정

• HSTS를 HTTP 응답에 설정: HSTS 헤더는 https:// 응답에서만 브라우저가 인정합니다. HTTP로 보내면 무시되므로, HTTP는 HTTPS로 리다이렉트하고 HSTS는 HTTPS 응답에 실어야 합니다.
• 등급 A를 안전하다고 착각: 6/6이라도 CSP에 'unsafe-inline'이 들어 있으면 XSS 방어는 거의 무의미합니다. 존재 여부와 값의 품질은 별개입니다.