응답 헤더, 리디렉션 및 보안 검사
DNS 및 레코드
DNS 조회 모든 도메인의 전체 DNS 레코드 A 레코드 조회 도메인의 IPv4 주소 AAAA 레코드 조회 도메인의 IPv6 주소 MX 조회 도메인의 메일 서버 NS 조회 권한 있는 네임 서버 TXT 조회 TXT 레코드, SPF, 인증 CNAME 조회 정규 이름(별칭) 레코드 SOA 조회 Start of Authority 레코드 SRV 조회 서비스 위치 레코드 CAA 조회 어떤 CA가 인증서를 발급할 수 있는지 역방향 DNS (PTR) IP 주소에서 호스트명으로 DNSSEC 점검 도메인이 서명되고 검증되는가? DNS 헬스 체크 위임 및 DNS 전체를 진단하는 종합 리포트이메일 전달성
SPF 점검 Sender Policy Framework 레코드 검증 DMARC 점검 DMARC 정책 검사 및 등급 평가 DKIM 점검 DKIM 공개 키 찾기 및 검증 블랙리스트 점검 이메일 차단 목록(DNSBL)에 대해 IP 점검 SMTP 테스트 메일 서버에 연결하여 STARTTLS 점검 MTA-STS 점검 수신 메일에 대한 강제 TLS 정책 BIMI 점검 이메일용 브랜드 로고 레코드 TLS-RPT 점검 SMTP TLS 보고 정책네트워크 및 웹
SSL 인증서 점검 사이트의 TLS 인증서 및 만료 검사 HTTP 헤더 점검 응답 헤더, 리디렉션 및 보안 검사 핑 (TCP) TCP를 통한 도달성 및 지연 시간 포트 점검 어떤 일반 포트가 열려 있는지도메인
WHOIS 조회 도메인, IP 및 ASN의 등록 데이터HTTP 응답 헤더는 웹 서버가 어떻게 동작하는지를 드러냅니다. 반환하는 상태 코드, 리디렉션 위치, 실행 중인 소프트웨어, 전송하는 보안 강화 헤더 등입니다. HSTS, Content-Security-Policy, X-Frame-Options 같은 헤더가 누락되면 사이트가 다운그레이드, 인젝션, 클릭재킹 공격에 노출됩니다. IPeek는 전체 리디렉션 체인을 따라가 응답을 핵심 보안 헤더 기준으로 평가합니다.
모든 HTTP 응답은 페이지 본문에 앞서 상태 코드와 일련의 헤더로 시작합니다. 상태 코드는 클라이언트에 무슨 일이 일어났는지 알려 줍니다. 200은 성공, 301과 302는 리소스가 이동했음을, 404는 찾을 수 없음을, 5xx는 서버 실패를 의미합니다. 헤더는 Content-Type, Server, Cache-Control 같은 메타데이터와 브라우저가 페이지를 어떻게 다룰지 지시하는 보안 디렉티브를 담습니다. IPeek는 URL을 요청해 서버가 보낸 그대로 헤더를 포착하고, 각 리디렉션을 따라가 최종 응답까지의 전체 경로를 보여 줍니다.
먼저 최종 상태 코드가 예상한 것인지 확인하세요. 정상 페이지라면 보통 200입니다. 그런 다음 리디렉션 체인을 따라가세요. 잘 구성된 설정은 HTTP를 HTTPS로, 비표준 호스트를 표준 호스트로 가능한 한 적은 단계로 리디렉션합니다. 추가되는 리디렉션마다 지연이 늘기 때문입니다. 리디렉션 루프나 잘못된 호스트로 끝나는 체인을 주의하세요. Server 헤더는 사용 중인 소프트웨어를 드러내고, 보안 헤더 등급은 어떤 보호 헤더가 있고 없는지를 한눈에 보여 줍니다.
Strict-Transport-Security(HSTS)는 브라우저가 HTTPS를 사용하도록 강제해 다운그레이드 공격을 막습니다. Content-Security-Policy는 스크립트와 리소스를 어디에서 로드할 수 있는지 제한하여 크로스 사이트 스크립팅에 대한 가장 강력한 방어를 제공합니다. X-Frame-Options 또는 CSP의 frame-ancestors 디렉티브는 페이지를 누가 임베드할 수 있는지 제어해 클릭재킹을 막습니다. X-Content-Type-Options: nosniff는 MIME 스니핑을 차단합니다. 가장 흔한 빈틈은 이 헤더를 하나도 제공하지 않아 브라우저에 추가 보호가 없는 사이트입니다. 웹 서버나 CDN에서 추가한 뒤, 실시간 응답에 나타나는지 다시 확인하세요.
배포 후, CDN이나 리버스 프록시를 변경한 후, 그리고 사이트의 보안 태세를 강화할 때마다 헤더를 점검하세요. 이러한 순간에 헤더가 추가, 누락 또는 덮어쓰기되기 때문입니다. HTTP에서 HTTPS로의 리디렉션이 실제로 작동하는지 확인하거나, 예기치 않은 리디렉션 체인을 디버깅하거나, 설정한 보안 헤더가 전달 경로 어딘가에서 제거되지 않고 실제 브라우저에 도달하는지 검증하는 가장 빠른 방법입니다.
사이트가 반환하는 상태 코드, 리디렉션 체인, 서버 소프트웨어, 보안 헤더를 보여 줍니다. URL이 올바르게 리디렉션되는지, 몇 단계를 거치는지, 어떤 서버가 응답하는지, HSTS와 Content-Security-Policy 같은 보호 헤더가 있는지 없는지를 알 수 있습니다. 그래서 라우팅 문제와 보안 빈틈을 모두 빠르게 진단할 수 있습니다.
HTTP Strict-Transport-Security는 브라우저가 정해진 기간 동안 HTTPS로만 연결하도록 지시하는 헤더입니다. 공격자가 안전하지 않은 HTTP 연결을 강제하는 다운그레이드 및 중간자 공격을 막아 주기 때문에 중요합니다. 브라우저가 HSTS를 한 번 인식하면 정책이 만료될 때까지 해당 호스트에 대한 평문 HTTP를 거부하여 실제 공격 창구를 닫습니다.
리디렉션 체인은 보통 각각 한 가지를 처리하는 별도 규칙들이 쌓이면서 생깁니다. HTTP에서 HTTPS로, non-www에서 www로, 후행 슬래시 정규화 등입니다. 단계마다 지연과 오류 가능성이 더해집니다. 가능하면 최종 표준 URL로 향하는 하나의 리디렉션으로 합치고, 두 규칙이 요청을 서로 주고받는 루프를 주의하세요.
최소한 Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff, 그리고 X-Frame-Options나 CSP frame-ancestors를 통한 프레임 보호를 전송하세요. HSTS는 HTTPS를 강제하고, CSP는 스크립트 인젝션을 제한하며, nosniff는 MIME 혼동을 막고, 프레임 보호는 클릭재킹을 차단합니다. 이들을 함께 쓰면 서버나 CDN에서 한 번 설정하는 디렉티브로 가장 흔한 브라우저 측 공격 유형을 막을 수 있습니다.
301은 영구 리디렉션이고 302는 임시 리디렉션입니다. 301은 리소스가 영구적으로 이동했음을 브라우저와 검색 엔진에 알려, 북마크를 갱신하고 순위 신호를 새 URL로 전달하게 합니다. 302는 이동이 임시임을 알려 클라이언트가 원래 URL을 계속 사용하게 합니다. 표준화 및 HTTPS 리디렉션에는 301을 사용하세요.