이런 분께 유용합니다
- 웹 배포 전 응답 헤더를 빠르게 점검하려는 개발자
- 프록시·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 Header 분석기란?
HTTP Header 분석기는 웹사이트 응답 헤더를 붙여넣어 보안, 캐시, CORS, 콘텐츠 타입, 쿠키 보안 설정을 빠르게 점검할 수 있는 무료 개발자 유틸리티입니다.
Nginx, Apache, Django, Node.js, CDN, 리버스 프록시 설정을 점검하거나 배포 전 보안 헤더 누락 여부를 확인할 때 활용할 수 있습니다.
주요 점검 항목
- Strict-Transport-Security: HTTPS 강제 사용 여부
- Content-Security-Policy: 스크립트, 이미지, 프레임 출처 제한
- X-Frame-Options: 클릭재킹 방지
- X-Content-Type-Options: MIME 타입 스니핑 방지
- Referrer-Policy: 외부 이동 시 referrer 전달 범위 제어
- Permissions-Policy: 브라우저 기능 사용 권한 제한
- Cache-Control: 브라우저 캐시 정책
- Set-Cookie: Secure, HttpOnly, SameSite 옵션 확인
이런 작업에 활용할 수 있습니다
- 웹사이트 배포 전 보안 헤더 누락 점검
- Nginx 또는 Apache 응답 헤더 설정 확인
- Django, Node.js, Spring 서비스의 보안 헤더 확인
- CDN 적용 후 캐시 정책 확인
- CORS 오류 원인 점검
- 쿠키 보안 옵션 확인
HTTP Header는 어디서 확인할 수 있나요?
브라우저 개발자 도구의 Network 탭에서 요청을 선택한 뒤 Response Headers를 복사하거나, 터미널에서 curl -I https://example.com 명령으로 확인할 수 있습니다.
HSTS는 무조건 켜도 되나요?
HSTS는 HTTPS 사용을 강제하는 강력한 보안 헤더입니다. 사이트 전체가 HTTPS로 안정적으로 동작하고 하위 도메인까지 문제가 없을 때 적용하는 것이 좋습니다. 잘못 적용하면 HTTP 접근이 필요한 하위 도메인에 문제가 생길 수 있습니다.
CSP가 없으면 위험한가요?
Content-Security-Policy는 XSS 공격 완화에 도움을 주는 중요한 보안 헤더입니다. 다만 서비스에서 사용하는 스크립트, 이미지, CDN 출처를 정확히 파악한 뒤 점진적으로 적용하는 것이 안전합니다.
Cache-Control은 어떻게 설정해야 하나요?
이미지, CSS, JS 같은 정적 파일은 긴 캐시를 사용할 수 있지만, HTML이나 사용자별 응답은 짧은 캐시 또는 no-cache 전략이 필요할 수 있습니다. 콘텐츠 종류와 배포 방식에 따라 정책을 다르게 설정하는 것이 좋습니다.
CORS에서 Access-Control-Allow-Origin: * 설정은 안전한가요?
공개 API나 정적 리소스라면 사용할 수 있지만, 인증 정보가 포함되는 요청에는 신중해야 합니다. 쿠키나 인증 토큰이 필요한 API는 허용할 origin을 명확히 제한하는 것이 좋습니다.
Set-Cookie 보안 옵션은 왜 중요한가요?
Secure는 HTTPS에서만 쿠키를 전송하게 하고, HttpOnly는 JavaScript에서 쿠키 접근을 제한하며, SameSite는 CSRF 위험을 줄이는 데 도움을 줍니다.
이 도구만으로 보안 점검이 완료되나요?
이 도구는 입력한 HTTP Header 텍스트를 기준으로 빠르게 점검하는 보조 도구입니다. 실제 보안 수준은 서버 설정, 애플리케이션 코드, 인증 방식, 쿠키 정책, HTTPS 구성까지 함께 확인해야 합니다.
HTTP 응답 헤더를 읽고 보안·캐시 설정을 점검하는 법
개발자 도구나 curl에서 복사한 HTTP 응답 헤더를 붙여넣어 HSTS, CSP, 프레임 제한, MIME 스니핑, Referrer Policy, CORS, 캐시와 쿠키 옵션을 빠르게 확인하는 도구입니다. 점수는 우선순위를 돕는 휴리스틱이며 사이트의 취약점이나 규정 준수를 인증하지 않습니다.
대표 활용 상황
- 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
수정된 실제 응답을 다시 수집하고 전문 스캐너와 수동 테스트로 검증합니다.
HTML 보안 헤더 점검
- 입력
- content-type, strict-transport-security, content-security-policy, x-content-type-options 포함
- 결과
- 주요 헤더 존재와 일부 값 패턴을 항목별로 표시
CSP가 존재해도 허용 범위가 지나치게 넓을 수 있으므로 정책 전체의 안전성을 이 점수만으로 판단할 수 없습니다.
인증 쿠키 점검
- 입력
- Set-Cookie: session=가림; Secure; HttpOnly; SameSite=Lax
- 결과
- 세 가지 보안 속성 포함 여부를 확인
쿠키 Domain, Path, 수명과 SameSite 값의 업무 적합성까지 완전히 평가하지는 않습니다. 실제 토큰 값은 붙여넣지 마세요.
계산·처리 기준
붙여넣은 각 줄의 첫 콜론을 기준으로 필드 이름과 값을 분리하고 이름을 소문자로 정규화합니다. 여러 Set-Cookie는 개별 값으로 유지하며 주요 보안·캐시·CORS 헤더의 존재와 일부 권장 패턴에 가중치를 부여해 0~100 점수로 환산합니다. 어떤 URL에도 요청을 보내지 않습니다.
알아둘 한계
- 헤더 존재 여부와 단순 패턴만 보므로 CSP 우회, CORS 자격 증명 조합과 캐시 오염 가능성을 완전히 분석하지 않습니다.
- CORS 헤더가 없거나 쿠키가 없다는 사실은 응답의 목적에 따라 양호 또는 무관할 수 있습니다.
- 리디렉션 단계, HTTP 메서드와 콘텐츠 유형에 따라 헤더가 달라질 수 있으므로 한 응답만으로 전체 사이트를 대표할 수 없습니다.
- 보안 점수는 취약점 진단, 침투 테스트, 법적·규제 준수 인증이 아닙니다.
개인정보 처리
붙여넣은 헤더는 현재 브라우저에서만 파싱하며 win-j 서버나 대상 URL로 전송하지 않습니다. 하지만 원문에 세션 쿠키·Bearer 토큰·내부 호스트가 포함될 수 있으므로 입력 전에 반드시 삭제하거나 마스킹하세요.
참고 자료
함께 쓰면 좋은 도구
- Open Graph 미리보기
HTML head에 넣을 공유 메타데이터를 시각적으로 점검합니다.
- Docker Compose 생성기
프록시와 애플리케이션 서비스 구성 초안을 만듭니다.
자주 묻는 질문
URL을 입력하면 사이트 헤더를 자동으로 가져오나요?
아닙니다. SSRF와 CORS 문제를 피하기 위해 사용자가 붙여넣은 텍스트만 분석합니다.
100점이면 안전한 사이트인가요?
아닙니다. 제한된 헤더의 존재와 패턴만 보는 참고 점수입니다. 애플리케이션 취약점과 실제 정책 내용은 별도 검증해야 합니다.
Set-Cookie 원문을 그대로 붙여도 되나요?
권장하지 않습니다. 세션 ID와 인증 값은 가리고 Secure, HttpOnly, SameSite 같은 속성만 남겨 점검하세요.