보안 헤더 검사기

사이트 URL을 입력하면 HSTS, CSP, X-Frame-Options 등 주요 보안 헤더의 설정 상태를 진단합니다. 누락되었거나 설정이 미흡한 항목을 목록으로 보여주고 개선 방법도 함께 확인할 수 있습니다.

마지막 업데이트: 2026-09-20

공개된 사이트의 보안 헤더를 진단하기

URL을 넣으면 서버가 그 사이트에 접속해 응답 헤더를 받아 오고, HSTS·CSP·X-Frame-Options·X-Content-Type-Options·Referrer-Policy·Permissions-Policy의 설정 상태를 판정합니다. 빠진 것과, 있기는 하되 약한 것을 갈라 보여 주며 각각 무엇이 문제가 되는지를 덧붙입니다.

**여기서 새겨 둘 것은, 헤더가 「있다」는 것과 「듣는다」는 것은 별개라는 점입니다.** 이를테면 HSTS가 붙어 있어도 `max-age`가 짧으면 브라우저가 HTTPS를 강제하는 기간이 모자라 실제 보호는 얇아집니다. 이 도구가 합격과 경고를 가르는 까닭이 여기에 있습니다. **또 하나, 돌아온 헤더가 반드시 원본 서버가 붙인 것이라고는 할 수 없습니다.** CDN이나 리버스 프록시가 중간에 얹는 경우가 있고, 그렇다면 설정을 고칠 자리도 달라집니다. 진단이 보여 주는 것은 「밖에서 보이는 상태」이지, 어느 층이 붙였는지까지는 알 수 없습니다.

사용하는 방법

살펴볼 URL을 넣습니다 `https://`로 시작하는, 밖에서 닿을 수 있는 URL을 넣습니다.
검사를 실행합니다 **사설 IP 주소처럼 밖에서 닿을 수 없는 대상은 안전을 위해 거부됩니다.**
판정을 읽습니다 합격·경고·불합격의 세 단계로 나오며, 경고는 「있지만 약함」을 뜻합니다.
설명을 실마리로 고칩니다 항목마다 무엇이 문제인지가 붙어 있어 손댈 차례를 정할 수 있습니다.

더 잘 활용하기 위한 팁

이 도구는 대상 사이트의 URL을 서버 측에서 가져오기 때문에 브라우저의 CORS 제한을 받지 않고 어떤 사이트의 헤더든 진단할 수 있습니다.
HSTS의 max-age는 기본적으로 길수록 안전하지만, 인증서 운영 방식을 변경할 예정이라면 먼저 짧은 값으로 테스트한 후 운영 환경에 반영하세요.
자매 도구인 CSP 검증기와 함께 사용하면 Content-Security-Policy의 구문까지 자세히 검사할 수 있습니다.
robots.txt 검사기와 동일한 "URL을 입력하면 서버 측에서 가져오는" 방식을 사용하므로 인증이 필요 없는 공개 페이지라면 어떤 사이트든 진단 대상이 될 수 있습니다.
정기적으로 자사 사이트를 점검하여 CDN이나 리버스 프록시 설정 변경으로 보안 헤더가 의도치 않게 사라지지 않았는지 확인하는 습관을 들이세요.

이럴 때 쓸 수 있습니다

공개 전 마지막 확인을 할 때

내보내기 직전에 뜻한 헤더가 실제로 돌아오는지를 밖에서 확인할 수 있습니다.

다른 사이트의 설정을 참고할 때

**같은 분야의 사이트가 어디까지 해 두었는지를 보면 우리 수준을 재는 잣대가 됩니다.**

설정 변경의 전후를 견줄 때

헤더를 더한 뒤 다시 검사해 반영되었는지 확인할 수 있습니다.

넘겨받은 사이트를 점검할 때

**인수인계 직후의 톺아보기에 알맞아** 무엇이 빠졌는지를 한눈에 짚을 수 있습니다.

보안 헤더 용어

HSTS: HTTP가 아닌 HTTPS로 접속하도록 강제하는 헤더입니다. **`max-age`가 1년 이상이 아니면 보호의 기간이 모자랍니다.**
X-Content-Type-Options: `nosniff`를 넣으면 브라우저가 내용을 보고 MIME 타입을 넘겨짚는 일을 그만두어, 파일이 엉뚱하게 실행되는 것을 막습니다.
X-Frame-Options: 우리 사이트를 프레임에 끼워 넣지 못하게 하는 헤더입니다. **새 정책에서는 CSP의 `frame-ancestors`가 같은 몫을 합니다.**
Content-Security-Policy: 불러와도 되는 자원의 출처를 제한하는 장치로, XSS 방어의 중심입니다.
Referrer-Policy: 다른 사이트로 옮겨 갈 때 참조한 URL을 어디까지 넘길지를 정하는 헤더입니다.
Permissions-Policy: 카메라·마이크·위치 같은 기능을 어느 출처에 허용할지를 다스리는 헤더입니다.

자주 묻는 질문

기능 면에서는 비슷한 진단을 제공하지만, Toolbase의 검사기는 한국어로 결과와 개선 이유를 확인할 수 있다는 점이 다릅니다. 자세한 CSP 구문 검사는 자매 도구인 CSP 검증기가 담당합니다.

사용할 수 있지만, HSTS는 HTTPS 접속에만 의미가 있는 헤더이므로 HTTP만 사용하는 사이트에서는 HSTS 항목이 항상 불합격으로 진단됩니다. 먼저 사이트 전체를 HTTPS로 전환하는 것을 우선하세요.

현재는 Content-Security-Policy의 frame-ancestors 지시어가 권장되지만, 이를 지원하지 않는 구형 브라우저도 존재하므로 두 가지를 함께 명시하여 이중으로 대비하는 것이 실무상의 정석입니다.

아니요. 입력한 URL로의 요청은 그 자리에서만 이루어지며, 가져온 헤더 정보를 서버 측에 저장하지 않습니다.

반드시 그런 것은 아닙니다. 특히 Permissions-Policy는 필수가 아닌 추가 방어 계층이며, 사이트의 성격에 따라 우선순위가 낮을 수도 있습니다. 먼저 HSTS·CSP·X-Frame-Options 등 영향이 큰 항목부터 개선하는 것을 권장합니다.

여담 ― securityheaders.com과 클릭재킹 대책의 역사

HTTP 응답 헤더를 통한 보안 설정 진단은 Scott Helme이 개발한 "securityheaders.com"이 오랫동안 사실상의 표준으로 알려져 있습니다. 해외 서비스는 진단 결과와 개선 이유 설명이 영어로만 제공되는 경우가 많아, Toolbase에서는 이 분야의 대안으로 한국어로 결과와 개선 이유를 함께 확인할 수 있는 자체 검사기를 마련했습니다.

HSTS(HTTP Strict Transport Security)는 2012년 IETF가 RFC 6797로 표준화한 헤더입니다. 그 배경에는 사용자가 https://를 생략하고 입력했을 때 한 번은 HTTP로 접속하게 되고, 그 순간을 노려 통신 내용을 조작하는 "SSL 스트리핑"이라는 공격 기법이 2009년에 실제로 시연된 사건이 있습니다. HSTS는 브라우저가 "이 도메인은 항상 HTTPS로 접속해야 한다"고 기억하게 하여 최초 접속 이후의 다운그레이드 공격을 방지합니다.

X-Frame-Options는 2009년 마이크로소프트가 Internet Explorer 8을 위해 도입한 독자 확장 헤더로, 이후 다른 브라우저에도 채택되어 사실상의 표준이 되었습니다. 당시 문제가 되었던 것은 "클릭재킹"이라는 공격으로, 투명한 iframe을 진짜처럼 보이는 버튼 위에 겹쳐 사용자가 인지하지 못한 채 클릭하게 만드는 수법이었습니다. 현재는 더 유연하게 지정할 수 있는 Content-Security-Policy의 frame-ancestors 지시어로 이전이 진행되고 있지만, 이를 지원하지 않는 구형 브라우저를 위한 대비책으로 두 헤더를 함께 명시하는 것이 여전히 권장됩니다.

모든 여담 보기