이런 분께 유용합니다
- 웹 배포 전 응답 헤더를 빠르게 점검하려는 개발자
- 프록시·CDN·애플리케이션 계층의 헤더 차이를 비교하는 운영자
- 보안 헤더와 캐시·쿠키 옵션의 역할을 학습하는 사용자
Developer Network Utility
HTTP Header 분석기
HTTP 응답 헤더를 붙여넣으면 보안 헤더, 캐시 정책, CORS 설정, 콘텐츠 타입, 쿠키 보안 옵션을 한 번에 점검할 수 있는 개발자용 Header 분석 도구입니다.
보안 헤더 점검
HSTS, CSP, X-Frame-Options, Referrer-Policy 등 주요 보안 헤더를 확인합니다.
캐시 정책 분석
Cache-Control, ETag, Expires 설정을 확인해 정적 파일과 HTML 캐시 상태를 점검합니다.
CORS·쿠키 확인
Access-Control 헤더와 Set-Cookie의 Secure, HttpOnly, SameSite 옵션을 함께 확인합니다.
HTTP Header 입력
브라우저 개발자 도구 Network 탭 또는 curl -I 결과에서 응답 헤더를 복사해 붙여넣으세요.
분석 기준
응답 헤더 이름은 대소문자를 구분하지 않고 분석합니다.
권장 점검
보안 헤더, 캐시 헤더, CORS, 쿠키 옵션을 종합해 점수를 계산합니다.
Header 분석 점수
0점
응답 헤더를 입력한 뒤 분석을 실행하세요.
0%
분석 결과
주요 HTTP Header의 존재 여부와 권장 상태를 양호, 주의, 위험 기준으로 확인합니다.
아직 분석 결과가 없습니다.
파싱된 Header
입력된 응답 헤더를 key-value 형태로 정리해 보여줍니다.
아직 파싱된 헤더가 없습니다.
상세 리포트
분석 결과를 복사하거나 다운로드해 서버 설정 개선 체크리스트로 사용할 수 있습니다.
HTTP 응답 헤더를 입력한 뒤 HTTP Header 분석하기 버튼을 눌러주세요.
Header 점검 항목 비교
HTTP Header는 보안, 캐시, CORS, 쿠키 정책처럼 운영 품질과 직접 연결되는 항목을 포함합니다.
보안 Header
HSTS, CSP, X-Frame-Options, X-Content-Type-Options는 HTTPS 강제, 클릭재킹 방지, MIME 스니핑 방지에 도움을 줍니다.
캐시 Header
Cache-Control, ETag, Expires는 브라우저 캐시와 CDN 캐시 전략을 판단하는 데 사용됩니다.
CORS·Cookie
Access-Control-Allow-Origin과 Set-Cookie 옵션은 외부 요청 허용 범위와 세션 보안 상태를 확인할 때 중요합니다.
HTTP 응답 헤더를 읽고 보안·캐시 설정을 점검하는 법
복사한 HTTP 응답 헤더에서 보안·캐시·CORS·쿠키 항목을 확인합니다. 여러 HTTP 상태 블록을 붙여 넣으면 마지막 응답만 분석하며, 점수는 사이트 안전성을 인증하는 지표가 아닙니다.
대표 활용 상황
- HTML 응답에 CSP와 HSTS가 실제로 붙었는지 확인할 때
- 정적 파일과 API 응답의 Cache-Control 정책을 비교할 때
- Set-Cookie의 Secure·HttpOnly·SameSite 누락을 1차 확인할 때
처음부터 결과 확인까지
- 1
브라우저 Network 탭이나 curl -I로 최종 응답 헤더를 가져옵니다.
- 2
세션 ID와 인증 토큰이 포함된 Set-Cookie 값은 제거하거나 가린 뒤 붙여넣습니다.
- 3
쿠키와 캐시 점검 옵션을 응답 성격에 맞게 선택합니다.
- 4
분석 후 양호·주의·위험 항목의 설명을 점수보다 먼저 읽습니다.
- 5
헤더를 설정하는 애플리케이션·프록시·CDN 계층을 찾아 수정합니다.
- 6
수정된 실제 응답을 다시 수집하고 전문 스캐너와 수동 테스트로 검증합니다.
리디렉션 뒤 최종 응답
- 입력
- HTTP/1.1 301 Moved Permanently X-Frame-Options: DENY HTTP/2 200 Content-Type: text/html
- 결과
- 최종 응답의 Content-Type만 분석합니다.
리디렉션에 있던 보호 헤더를 최종 응답의 점수에 합산하지 않습니다.
쿠키 속성 점검
- 입력
- Set-Cookie: session=example; Secure; HttpOnly; SameSite=Lax
- 결과
- 세 속성의 포함 여부를 점검합니다.
example은 설명용 값이며 실제 세션 토큰을 입력하지 않습니다.
계산·처리 기준
각 줄의 첫 콜론으로 이름과 값을 나누고 이름은 소문자로 정리합니다. Set-Cookie 같은 중복 필드는 개별 값으로 유지합니다. 새 HTTP 상태 행이 나오면 기존 헤더를 비워 마지막 응답만 간단한 보안·캐시·CORS 규칙으로 평가하며, 직접 URL을 요청하지 않습니다.
알아둘 한계
- 점수는 헤더 존재와 단순 패턴을 보는 참고값이며 보안 인증이 아닙니다.
- CSP·CORS·캐시는 실제 정책값과 응답의 용도를 함께 검토해야 합니다.
- HTTP 상태 행으로 응답 블록을 구분합니다. 상태 행 없는 여러 응답은 따로 붙여 넣으세요.
- 한 응답만으로 다른 메서드·콘텐츠 유형·리디렉션 단계까지 대표할 수 없습니다.
개인정보 처리
붙여넣은 헤더는 현재 브라우저에서만 파싱하며 win-j 서버나 대상 URL로 전송하지 않습니다. 하지만 원문에 세션 쿠키·Bearer 토큰·내부 호스트가 포함될 수 있으므로 입력 전에 반드시 삭제하거나 마스킹하세요.
참고 자료
함께 쓰면 좋은 도구
- Open Graph 미리보기
HTML head에 넣을 공유 메타데이터를 시각적으로 점검합니다.
- Docker Compose 생성기
프록시와 애플리케이션 서비스 구성 초안을 만듭니다.
자주 묻는 질문
URL을 입력하면 사이트 헤더를 자동으로 가져오나요?
아닙니다. SSRF와 CORS 문제를 피하기 위해 사용자가 붙여넣은 텍스트만 분석합니다.
100점이면 안전한 사이트인가요?
아닙니다. 제한된 헤더의 존재와 패턴만 보는 참고 점수입니다. 애플리케이션 취약점과 실제 정책 내용은 별도 검증해야 합니다.
Set-Cookie 원문을 그대로 붙여도 되나요?
권장하지 않습니다. 세션 ID와 인증 값은 가리고 Secure, HttpOnly, SameSite 같은 속성만 남겨 점검하세요.