Skip to main contentSkip to navigation

Security Headers Analyzer

Analyze HTTP response headers for security best practices

HTTP Response Headers

Paste raw response headers (from your server, curl -I, or browser devtools).

Analysis

HSTS
Header not present
Forces HTTPS and protects against protocol downgrade attacks.
CSP
Header not present
Mitigates XSS by whitelisting sources.
X-Frame-Options
Header not present
Prevents clickjacking in iframes.
X-Content-Type-Options
Header not present
Prevents MIME sniffing.
Referrer-Policy
Header not present
Controls referer leakage.
Permissions-Policy
Header not present
Restricts powerful browser features.
COOP
Header not present
Isolates browsing context for security.
COEP
Header not present
Required for certain isolation models.
CORP
Header not present
Restricts cross-origin resource loading.

보안 헤더 분석기 - HTTP 응답 헤더 확인

HTTP 보안 헤더는 웹 취약점에 맞서는 1차 방어선입니다. 브라우저에 보안 정책 적용을 지시하여 XSS, 클릭재킹, MITM, 정보 유출로부터 사용자를 보호합니다. 이 분석기는 응답 헤더를 모범 규범과 비교 평가하고, 누락된 보호를 찾아내며, 애플리케이션을 단단하게 만드는 실행 가능한 권고를 제공합니다. 적절한 설정은 컴플라이언스, 신뢰, 변화하는 위협에 대한 방어에 필수입니다.

필수 보안 헤더와 보호 메커니즘

Content‑Security‑Policy(CSP)는 리소스 출처와 인라인 스크립트를 제어해 XSS를 방지합니다. Strict‑Transport‑Security(HSTS)는 HTTPS를 강제하여 다운그레이드 공격을 막습니다. X‑Frame‑Options 및 frame‑ancestors는 iframe 임베딩을 제어해 클릭재킹을 차단합니다. X‑Content‑Type‑Options는 MIME 스니핑을 방지합니다. Referrer‑Policy는 정보 노출을 제한하고, Permissions‑Policy는 카메라/마이크/위치 등 브라우저 API 접근을 제한합니다. 이 헤더들은 함께 심층 방어를 구성합니다.

CSP: 고급 설정과 모범 사례

CSP는 보안과 기능의 균형 잡힌 구성이 중요합니다. 먼저 제한적인 정책(default‑src 'self'; img‑src 'self' data:; style‑src 'self' 'unsafe‑inline'; script‑src 'self')으로 시작하고 필요에 따라 완화하세요. 'unsafe‑inline' 대신 nonce/hash를 사용합니다. report‑only로 도입→호환성 문제 해결→강제 적용 순으로 점진 적용하고, 리포트를 모니터링해 공격/오구성을 탐지하세요. 복잡한 앱은 페이지별 정책이나 strict‑dynamic을 고려합니다.

HSTS 도입과 서브도메인 고려 사항

HSTS는 향후 연결에서 HTTPS를 강제하여 SSL 스트리핑을 방지합니다. 테스트에서는 짧은 max‑age로 시작하고 운영에서는 점진적으로 늘리세요. 'includeSubDomains'로 전체 서브도메인을 보호하기 전, 모두가 HTTPS를 지원하는지 확인하세요. 첫 방문부터 보호하려면 'preload'를 검토하세요. HSTS는 제거 후에도 브라우저에 남을 수 있으니, 배포 전 충분히 검증해야 합니다.

자주 발생하는 실수와 해결법

너무 관대한 CSP(script‑src '*' 또는 'unsafe‑eval')는 효과를 무력화합니다. 로그인에서 HSTS가 없으면 다운그레이드 공격에 취약합니다. 잘못된 X‑Frame‑Options는 정상 iframe 사용을 방해하거나 클릭재킹을 막지 못할 수 있습니다. X‑Frame‑Options와 frame‑ancestors 충돌에도 유의하세요. 다양한 브라우저/흐름에서 테스트하고, DevTools로 CSP 위반, HSTS 유효성, 중요 페이지의 헤더 존재를 확인하세요.

API/SPA에 알맞은 보안 헤더

API는 전통적 페이지와 다른 구성이 필요합니다. CORS는 교차 출처 접근을 제어하고, JSON 엔드포인트에서는 CSP 중요도가 낮을 수 있습니다. SPA는 동적 로딩을 허용하면서 XSS를 막기 위해 정교한 CSP가 필요합니다. COEP/COOP 같은 헤더로 격리를 강화하세요. API 게이트웨이와 CDN은 원본의 보안 헤더를 보존해야 하며, 모든 환경(dev/staging/prod)에서 일관되게 적용하세요.

모니터링, 컴플라이언스, 대규모 운영

Security Headers, Mozilla Observatory, CI/CD 자동 스캔 등으로 모니터링하세요. CSP 위반과 HSTS 리포트를 기록해 공격·오구성을 파악합니다. 대규모 환경에서는 구성 관리와 '정책 as 코드'로 일관 배포를 보장합니다. 정기 감사로 효과를 확인하고 신규 표준을 평가하세요. SOC 2, PCI DSS 같은 규정은 이러한 헤더 구현을 요구하기도 합니다.

Further reading

Security headers provide essential protection against web vulnerabilities with minimal performance impact. Implement progressively, monitor violations, test thoroughly across browsers and user flows, and maintain policies as your application evolves. Regular security header audits should be part of your security maintenance routine.