HTTP 헤더 확인

점수나 등급은 매기지 않습니다. 필요한 헤더는 사이트마다 다르기 때문입니다. 예를 들어 CSP 는 사이트 구조에 맞춰 설계해야 하고, COEP 를 켜면 다른 사이트의 이미지·영상을 끼워 넣는 페이지가 깨질 수 있습니다. 로그인이나 입력 양식이 없는 정적 페이지와 결제 페이지에 같은 기준을 댈 수도 없습니다. 그래서 이 도구는 "없다"는 사실과 "없으면 브라우저가 어떻게 한다"(예: Referrer-Policy 가 없으면 기본값 strict-origin-when-cross-origin)만 알려 줍니다. X-Frame-Options 가 없어도 CSP 의 frame-ancestors 가 있으면 같은 역할을 한다는 것처럼, 헤더끼리의 관계도 함께 따집니다.

요청 조건이 달라서입니다. 이 검사는 쿠키와 Origin 헤더 없이, Cloudflare 데이터센터에서 microlab-scan 이라는 이름으로 요청합니다. 그래서 로그인 상태에 따라 붙는 쿠키·헤더는 보이지 않고, Origin 을 보고 CORS 헤더를 붙이는 서버는 CORS 헤더 없이 답하며, 압축(Content-Encoding)도 브라우저가 받는 것과 다를 수 있습니다. 국가·기기에 따라 다른 서버나 CDN 이 답하는 사이트도 있습니다. 또 주소가 리다이렉트되면 여기 나오는 것은 마지막 응답의 헤더이고, 중간 리다이렉트 응답의 헤더는 나오지 않습니다. 같은 주소를 10분 안에 다시 검사하면 검사 서버에 저장된 결과가 나올 수 있습니다.

둘은 다른 장치입니다. Strict-Transport-Security 헤더는 한 번 방문한 브라우저가 기억하는 것이고, preload 목록은 브라우저에 처음부터 내장된 목록입니다. .dev·.app 처럼 최상위 도메인 전체가 목록에 들어 있는 경우도 있어서, 그 아래 주소는 헤더를 보내지 않아도 첫 방문부터 https 로만 접속합니다. 반대로 헤더에 preload 라고 적었다고 목록에 들어가는 것은 아닙니다 — hstspreload.org 에 신청해 요건(max-age 1년 이상, includeSubDomains, preload)을 통과해야 합니다. 이 도구는 최종 주소의 호스트 이름으로 hstspreload.org 를 조회한 결과를 그대로 보여 줍니다.

흔한 오해입니다. no-cache 는 "저장은 해도 되지만 쓸 때마다 서버에 바뀌었는지 확인하라"는 뜻이고(RFC 9111 §5.2.2.4), 아예 저장하지 말라는 것은 no-store 입니다(§5.2.2.5). 확인할 때 ETag 나 Last-Modified 가 있으면 서버는 바뀌지 않은 경우 본문 없이 304 로 답할 수 있어서, no-cache 도 전송량을 줄여 줍니다. max-age 와 Expires 가 함께 있으면 max-age 가 이기고(§5.3), 둘 다 없으면 캐시가 스스로 수명을 추정할 수 있습니다(§4.2.2). 이 도구의 "캐시" 항목은 이 규칙대로 "이 응답이 캐시에 어떻게 남는지"를 한 문장으로 요약합니다.

서버가 보냈지만 브라우저가 규칙상 버리는 쿠키입니다. SameSite=None 인데 Secure 가 없는 경우, http 응답이 Secure 쿠키를 보낸 경우, 이름이 __Secure- 로 시작하는데 Secure 가 없는 경우, __Host- 로 시작하는데 Secure·Path=/·Domain 없음을 다 갖추지 않은 경우, Domain 이 응답한 호스트를 포함하지 않는 경우입니다(RFC 6265bis 저장 모델). 이름과 값에 제어 문자가 있거나 이름+값이 4096바이트를 넘어도 버립니다. SameSite 를 아예 쓰지 않으면 저장은 되지만, Chrome 계열은 Lax 처럼 다뤄 다른 사이트에서 오는 요청에는 링크를 눌러 넘어오는 이동(GET) 외에는 실어 보내지 않습니다. 다만 Chrome 은 SameSite 를 지정하지 않은 쿠키에 한해 다른 사이트에서 오는 최상위 POST 이동에도 일부 실어 보내는 임시 완화책을 두고 있고(web.dev "SameSite cookies explained"), RFC 6265bis 는 이런 예외를 만들어진 지 2분 이내의 쿠키로 좁히라고 권합니다(§5.6.7.2). 쿠키 값은 판정에 쓰지 않으며, 이 검사기가 익명으로 받은 값이라 방문자의 로그인 정보와는 관계없습니다.

이 도구는 사실만 적습니다. RFC 9110 은 필요 이상으로 자세한 Server 값이 내부 구현을 드러낼 수 있으니 보내지 말라(SHOULD NOT)고 적고 있고(§10.2.4), 그래서 버전 번호가 보이면 그렇다고 표시합니다. 다만 헤더를 지운다고 취약점이 고쳐지지는 않으며, 소프트웨어 종류는 다른 단서로도 알아낼 수 있습니다. 버전 번호를 감추는 것보다 소프트웨어를 최신으로 유지하는 것이 실제 보호입니다.

아니요. 이 도구는 HTTP 응답 헤더만 봅니다. <meta http-equiv="Content-Security-Policy"> 나 <meta name="referrer"> 로 넣은 정책은 보지 않으므로, 헤더가 없다고 나와도 페이지 안에서 정했을 수 있습니다. 또 브라우저가 실제로 불러오는 스크립트·이미지 같은 하위 자원의 헤더는 주소를 따로 넣어 검사해야 합니다.

주소는 진단을 위해 microlab scan-api 로 전송되고, scan-api 가 그 주소(와 리다이렉트로 이어지는 주소)에 요청을 한 번 보내 받은 헤더를 돌려줍니다. HSTS preload 여부는 scan-api 가 hstspreload.org 에 최종 호스트 이름으로 물어봅니다. 사설·내부 대역 주소와 80·443 이외의 포트는 거부합니다. 헤더의 해석은 이 브라우저 안에서 합니다.