CSP 분석기

URL의 콘텐츠 보안 정책(CSP) 및 Content-Security-Policy-Report-Only를 분석합니다. 위험 지시문(unsafe-inline, 와일드카드), 누락된 논스/해시 전략, 사용 중단된 패턴을 감지하고 XSS 방어 강화를 위한 실행 가능한 권장 사항을 제공합니다. 리디렉션, 원시 헤더 검사, 필터링, 발견 사항, JSON/PDF 내보내기를 지원합니다.

Loading…

소개 CSP 분석기

URL을 붙여넣어 CSP 헤드를 검사하고 정책이 실제로 XSS 및 주입으로부터 보호하는지 빠르게 확인하세요. 이 분석기는 위험한 허용(unsafe-inline 또는 광범위한 와일드카드 등)을 강조 표시하고, 누락된 사항(논스/해시 전략, 프레임 제한)을 설명하며, report-only를 안전하게 사용하여 실용적이고 배포 가능한 CSP로 전환하는 데 도움을 줍니다.

기능

  • Content-Security-Policy 및 Content-Security-Policy-Report-Only 헤더 감지 및 설명.
  • 일반적인 CSP 함정 표시: unsafe-inline, unsafe-eval, 광범위한 와일드카드, 과도하게 허용적인 소스.
  • 논스 및 해시 기반 전략을 통한 안전한 스크립트/스타일 실행 지침.
  • 실제 강화에서 중요한 누락된 지시문 식별(예: frame-ancestors, object-src, base-uri).
  • Report-Only 통찰: 무엇이 차단될지 이해하고 프로덕션을 중단하지 않고 CSP를 롤아웃하는 방법.
  • 리디렉션(최대 10회)을 따라 최종 응답 정책을 분석하여 브라우저가 적용하는 정책 확인.
  • 정확한 서버 출력 및 디버깅을 위한 원시 헤더 보기.
  • 발견 사항 + '문제만' 필터링이 포함된 점수 카드.
  • 감사, 티켓 및 보안 검토를 위해 분석을 JSON 또는 PDF로 내보내기.
  • 레거시 정책 및 마이그레이션 요구 사항을 파악하기 위한 사용 중단된 헤더 인식 포함.

🧭 사용 방법 for csp-analyzer

1

분석할 URL 입력

확인하려는 페이지 URL을 붙여넣으세요(종종 홈페이지 또는 앱 셸).

2

필요한 경우 리디렉션 따라가기 활성화

분석기가 실제 CSP가 반환되는 최종 HTTPS/www/로케일 대상에 도달할 수 있도록 '리디렉션 따라가기'를 활성화 상태로 유지하세요.

3

점수 카드 및 발견 사항 검토

중요한 위험(unsafe-inline, 와일드카드, 누락된 제한)을 발견하고 점수를 결정하는 지시문을 이해하려면 발견 사항부터 시작하세요.

4

디버깅 시 원시 헤더 검사

정확한 헤더 이름/값을 확인하려면 '원시 헤더 표시'를 켜세요(여러 CSP 헤더가 있거나 프록시/CDN이 수정하는 경우 유용).

5

보안 워크플로우를 위한 보고서 내보내기

자동화를 위해 JSON을 다운로드하거나 보안 감사 및 엔지니어링 티켓을 위해 PDF를 다운로드하세요.

기술 사양

요청 모델

이 도구는 URL 헤더 검사를 수행하고 CSP 및 report-only 정책을 포함한 보안 헤더 분석에 중점을 둡니다.

설정동작기본값
리디렉션 따라가기리디렉션 체인을 따라 최종 URL이 반환하는 유효 정책을 분석합니다활성화됨
최대 리디렉션 횟수루프를 방지하기 위한 리디렉션 제한10
타임아웃요청 타임아웃 제한15000 ms
사용자 에이전트요청 사용자 에이전트를 식별합니다Encode64Bot/1.0 (+https://encode64.com)
사설 네트워크안전을 위해 사설 네트워크 범위 접근을 차단합니다비활성화됨 (사설 네트워크 허용 안 됨)

검사된 CSP 헤더

분석기는 강제 및 비강제 정책을 모두 확인하고 읽기 쉬운 형태로 표시합니다.

헤더의미
Content-Security-Policy브라우저에 의해 적용되는 강제 정책
Content-Security-Policy-Report-Only위반 사항을 보고하는 비차단 정책 (배포 및 조정에 유용함)
사이트는 여러 CSP 헤더를 내보낼 수 있습니다. 브라우저는 복잡할 수 있는 조합/우선순위 규칙을 적용합니다—원시 헤더는 전송되는 내용을 확인하는 데 도움이 됩니다.

분석 대상 항목

발견 사항은 실용적인 CSP 강화 검사 및 일반적인 배포 실수를 기반으로 합니다.

영역발견 사항 예시
스크립트 정책 강도unsafe-inline / unsafe-eval 사용, 와일드카드 소스, 누락된 nonce/hash 전략
스타일 정책 강도unsafe-inline 스타일, 지나치게 광범위한 소스, 가능한 경우 nonce/hash로의 마이그레이션 경로 누락
프레이밍 및 클릭재킹 방지누락되거나 약한 프레임 제한 (종종 frame-ancestors를 통해)
레거시 / 사용 중단된 패턴현대화해야 할 오래된 지시문 또는 패턴
배포 준비 상태Report-Only 정책 존재 및 보고 엔드포인트 가시성

명령줄

CSP 헤더를 빠르게 검사하려면 다음 명령어를 사용하세요. 분석기가 보고하는 내용을 검증하는 데 유용합니다.

macOS / Linux

응답 헤더 가져오기 (CSP 찾기)

curl -I https://example.com

응답 헤더에서 Content-Security-Policy와 Content-Security-Policy-Report-Only를 검사합니다.

헤더 확인하면서 리디렉션 따르기

curl -IL https://example.com

최종 목적지(HTTPS, www, 앱 셸 경로)의 CSP 헤더를 확인할 수 있도록 합니다.

CSP 헤더만 표시 (대소문자 구분 없음)

curl -I https://example.com | grep -i "content-security-policy"

전체 헤더 세트에서 CSP 및 report-only 헤더를 빠르게 분리합니다.

Windows (PowerShell)

CSP 헤더 검사

$r = Invoke-WebRequest -Uri https://example.com -Method Head; $r.Headers['Content-Security-Policy']; $r.Headers['Content-Security-Policy-Report-Only']

존재하는 경우 강제 및 report-only CSP 헤더를 표시합니다.

새로운 정책은 먼저 Report-Only로 배포하고, 위반 보고서를 검토한 후 강화하여 적용하세요. 현대적 앱의 CSP 조정은 반복적인 과정입니다.

사용 사례

XSS에 대한 사이트 강화

스크립트/스타일이 로드될 수 있는 출처와 인라인 코드 처리 방식을 제한하여 주입 취약점의 영향을 줄이기 위해 CSP를 사용하세요.

  • unsafe-inline/unsafe-eval 식별 및 nonce/해시로의 마이그레이션 계획 수립
  • script-src/style-src 출처를 신뢰할 수 있는 오리진으로 제한
  • 누락된 방어적 지시문 추가 (base-uri, object-src, frame-ancestors)

Report-Only로 CSP 안전하게 롤아웃

Content-Security-Policy-Report-Only로 시작하여 위반 사항을 반복적으로 개선함으로써 프로덕션을 중단하지 않고 점진적으로 CSP를 도입하세요.

  • report-only 정책 존재 감지
  • 적용 전에 차단될 내용 이해
  • 롤아웃 계획 및 티켓용 보고서 내보내기

깨진 스크립트, iframe 또는 서드파티 위젯 디버깅

지나치게 엄격한 CSP는 분석, 임베드 또는 API 연결을 차단할 수 있습니다. 분석기를 사용하여 정책이 허용하는 내용과 명시적 출처가 필요한 부분을 확인하세요.

  • 허용된 script/img/connect/frame 출처 확인
  • 빠른 수정으로 추가된 과도한 와일드카드 감지
  • 광범위한 허용을 대상 도메인으로 대체

보안 검토 / 규정 준수 증거

보안 검토, 고객 설문지 또는 내부 규정 준수를 위해 현재 CSP 상태에 대한 일관된 보고서를 생성하세요.

  • 시간 경과에 따른 변경 사항 추적을 위해 JSON 다운로드
  • 감사 아티팩트 및 공유를 위해 PDF 다운로드

❓ Frequently Asked Questions

❓CSP란 무엇이며 무엇으로부터 보호하나요?

콘텐츠 보안 정책(CSP)은 리소스가 로드될 수 있는 위치와 스크립트/스타일이 실행되는 방식을 제한하는 브라우저 강제 보안 계층입니다. 주로 크로스 사이트 스크립팅(XSS) 및 인젝션 공격의 영향을 줄이는 데 사용됩니다.

❓CSP와 CSP Report-Only의 차이점은 무엇인가요?

Content-Security-Policy는 강제 적용됩니다(차단 가능). Content-Security-Policy-Report-Only는 차단하지 않고 위반 사항을 보고하여 정책을 강제하기 전에 조정할 수 있게 합니다.

❓unsafe-inline이 위험한 것으로 간주되는 이유는 무엇인가요?

unsafe-inline은 인라인 스크립트/스타일을 허용하여 CSP가 주입된 코드를 차단하는 능력을 약화시킵니다. 더 안전한 접근 방식은 nonce나 해시를 사용하여 알려진 인라인 블록만 허용하면서도 예상치 못한 인젝션을 차단합니다.

❓nonce나 해시가 필요한가요?

앱이 인라인 스크립트나 스타일을 사용하는 경우, nonce/해시는 기능을 손상시키지 않으면서 CSP를 효과적으로 유지하는 현대적인 방법입니다. 이를 통해 특정 인라인 블록만 허용하면서 임의의 인젝션을 방지합니다.

❓CDN이나 프록시가 내 CSP 헤더를 변경할 수 있나요?

예. 엣지 계층은 헤더를 추가, 병합 또는 재정의할 수 있습니다. 일관성이 없어 보이는 경우 원시 헤더를 활성화하고 리디렉션을 따라 최종 응답 헤더를 확인하세요.

❓CSP는 XSS 버그 수정을 대체하나요?

아니요. CSP는 심층 방어 통제입니다. 여전히 적절한 출력 인코딩, 안전한 템플릿 및 입력 검증이 필요합니다. CSP는 무언가가 빠져나갈 경우 피해 범위를 줄입니다.

❓여기에 URL을 붙여넣는 것이 안전한가요?

이 도구는 제공된 URL에 대해 서버 측 요청을 수행하고 사설 네트워크 대상을 차단합니다. URL에 비밀 정보(쿼리 문자열의 토큰 등)를 넣지 말고 신뢰할 수 있는 공개 URL을 사용하세요.

Pro Tips

Best Practice

Content-Security-Policy-Report-Only로 시작하여 위반 사항을 수집한 후 강화하고 강제 적용하세요. CSP는 실제 앱에 대해 반복적입니다.

Best Practice

unsafe-inline을 nonce 또는 해시 전략으로 교체하세요. 정책을 명시적이고 최소화하여 유지하세요.

Best Practice

클릭재킹 위험을 줄이고 레거시 헤더에만 의존하지 않도록 frame-ancestors를 추가하세요.

Best Practice

빠른 해결책으로 광범위한 와일드카드를 피하세요. 스크립트/이미지/연결에 대해 대상 도메인을 선호하고 타사 요구 사항을 검토하세요.

CI Tip

JSON 보고서를 내보내고 CI에서 CSP 변경 사항을 추적하여 CDN/앱 업데이트 시 헤더가 수정될 때 회귀를 포착하세요.

Additional Resources

콘텐츠 보안 정책 (MDN)
Documentation
Content-Security-Policy 헤더 (MDN)
Documentation
Content-Security-Policy-Report-Only (MDN)
Documentation
XSS 가이드 (OWASP)
Documentation
CSP 치트 시트 (OWASP)
Documentation

Other Tools

CSP 분석기 — 콘텐츠 보안 정책 및 report-only 헤더 감사 | Encode64