CSP 검증기
CSP 헤더 파싱·위험 키워드 경고·누락 지시어 진단
| 지시어 | 값 |
|---|
CSP 검증이 중요한 이유
잘못 설정된 CSP는 사이트를 깨뜨리거나 보안 효과가 없을 수 있습니다. 'unsafe-inline'이 포함되면 XSS 공격이 가능하고, 와일드카드(*)는 모든 출처를 허용해 CSP 자체가 무의미해집니다. 검증을 통해 위험 키워드와 누락된 지시어를 확인하세요.
자주 묻는 질문
CSP 파싱 오류는 어떻게 확인하나요?
브라우저 개발자 도구 콘솔에서 CSP 위반 메시지를 확인할 수 있습니다. "Refused to execute inline script because it violates the following Content Security Policy directive" 형식의 메시지가 표시됩니다.
'unsafe-inline'을 없애면 사이트가 깨지는 경우는?
인라인 <script>, style 속성, onclick 핸들러 등이 차단됩니다. nonce 기반으로 교체하거나 외부 파일로 이동해야 합니다. Report-Only 모드로 먼저 테스트하세요.
frame-ancestors 'none'은 무엇을 막나요?
다른 어떤 페이지도 이 페이지를 <iframe>, <frame>, <object>로 삽입할 수 없게 합니다. 클릭재킹 공격을 완전히 차단하는 가장 강력한 설정입니다.
CSP와 XSS의 관계는?
CSP는 XSS 공격의 영향을 줄이는 방어 레이어입니다. 올바르게 설정된 CSP는 공격자가 스크립트를 삽입하더라도 실행을 차단합니다. 단, XSS 자체를 방지하는 것은 입력 검증과 출력 이스케이프입니다.
data: URI를 img-src에 허용해도 되나요?
img-src에 data:를 허용하면 base64 인코딩된 이미지를 인라인으로 사용할 수 있습니다. script-src나 style-src에 data:를 허용하면 심각한 보안 취약점이 됩니다.
https:와 http:의 차이는?
https:는 모든 HTTPS 도메인을 허용합니다. http:는 모든 HTTP 도메인을 허용하므로 보안상 좋지 않습니다. 가능한 한 구체적인 도메인을 명시하세요.
upgrade-insecure-requests 지시어란?
HTTP 리소스를 자동으로 HTTPS로 업그레이드하도록 지시합니다. mixed content 문제를 해결하는 데 유용합니다. block-all-mixed-content는 HTTP 리소스를 완전히 차단합니다.
CSP를 점진적으로 도입하는 방법은?
1) Report-Only 모드로 시작해 위반 사항 수집 → 2) 위반을 하나씩 수정 → 3) 실제 차단 모드로 전환. Google's CSP Evaluator 도구로 강도를 평가할 수 있습니다.