사이트를 망가뜨리지 않고 CSP 적용하기
Content Security Policy(CSP)가 사이트를 크로스 사이트 스크립팅(XSS) 및 데이터 주입 공격으로부터 보호하는 데 필수적이라는 말을 들어보셨을 것입니다. 하지만 CSP를 추가하려고 하면 사이트가 망가집니다: 이미지가 사라지고, 스크립트가 실행되지 않고, 스타일이 사라집니다. 보안과 기능성 사이의 타협처럼 느껴질 수 있습니다. 하지만 그럴 필요는 없습니다.
이 가이드에서는 사이트를 망가뜨리지 않고 CSP를 배포하는 실용적인 단계별 접근 방식을 배우게 됩니다. 핵심 지시문, nonce와 해시 사용 방법, 안전하게 테스트하는 방법을 다룹니다. 마지막에는 사용자 경험을 희생하지 않고 보안을 강화하는 작동하는 CSP를 갖게 될 것입니다.
CSP란 무엇이며 왜 사이트를 망가뜨리는가?
Content Security Policy는 페이지에서 로드할 수 있는 리소스(스크립트, 스타일, 이미지, 글꼴 등)를 제한할 수 있는 브라우저 보안 표준입니다. Content-Security-Policy: default-src 'self'와 같은 HTTP 헤더를 통해 전달됩니다.
CSP가 사이트를 망가뜨리는 이유는 정책에 맞지 않는 모든 리소스를 차단하기 때문입니다. 인라인 스크립트, CDN의 외부 스크립트 또는 인라인 스타일이 있는 경우 명시적으로 허용하지 않으면 차단됩니다. 기본 동작은 허용되지 않은 모든 것을 차단하는 것이므로 엄격한 정책은 사이트를 빠르게 망가뜨릴 수 있습니다.
핵심은 관대한 정책으로 시작하여 위반 사항을 모니터링하면서 점진적으로 강화하는 것입니다.
알아야 할 핵심 CSP 지시문
CSP는 지시문을 사용하여 다양한 리소스 유형을 제어합니다. 가장 일반적인 것들은 다음과 같습니다:
- default-src: 다른 지시문의 대체입니다. 여기서 시작하세요.
- script-src: JavaScript 소스를 제어합니다.
- style-src: CSS 소스를 제어합니다.
- img-src: 이미지 소스를 제어합니다.
- connect-src: AJAX, WebSocket, fetch 대상을 제어합니다.
- font-src: 웹 글꼴 소스를 제어합니다.
- frame-src: iframe 소스를 제어합니다.
- report-uri / report-to: 위반 보고서를 보낼 위치입니다.
하나의 헤더에 세미콜론으로 구분하여 여러 지시문을 설정할 수 있습니다. 예를 들어:
Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://images.example.com각 지시문은 공백으로 구분된 소스 목록을 허용합니다. 소스는 'self', 'unsafe-inline', 'unsafe-eval'과 같은 키워드, URL 또는 nonce/해시일 수 있습니다.
단계별: 사이트를 망가뜨리지 않고 CSP 배포하기
CSP를 안전하게 출시하려면 다음 단계를 따르세요.
- 보고 전용 정책으로 시작하세요. 적용 헤더 대신
Content-Security-Policy-Report-Only헤더를 사용하세요. 이렇게 하면 실제로 차단하지 않고 차단될 항목을 확인할 수 있습니다. - 관대한 정책을 설정하세요.
default-src 'self' 'unsafe-inline' 'unsafe-eval' https:와 같이 시작하여 대부분을 허용하세요. 이렇게 하면 중단을 최소화할 수 있습니다. - 위반 보고서를 수집하세요. 위반을 기록하는 엔드포인트로
report-uri를 구성하세요. 이 보고서를 검토하여 차단된 리소스를 식별하세요. - 위반 사항을 수정하세요. 인라인 스크립트/스타일을 피하도록 코드를 업데이트하거나 nonce/해시를 추가하세요. 외부 리소스를 허용된 도메인으로 이동하세요.
- 정책을 점진적으로 강화하세요. 리팩터링한 후
'unsafe-inline'및'unsafe-eval'을 제거하세요. 허용된 도메인을 좁히세요. - 적용 모드로 전환하세요. 보고서에 예상치 못한 차단이 없으면 헤더를
Content-Security-Policy로 변경하세요(-Report-Only없이). - 지속적으로 모니터링하세요. 새로운 문제를 포착하기 위해 보고 엔드포인트를 활성 상태로 유지하세요.
이 점진적 접근 방식은 보안을 개선하면서 사이트를 망가뜨리지 않도록 보장합니다.
인라인 스크립트에 nonce와 해시 사용하기
인라인 스크립트는 CSP 중단의 흔한 원인입니다. 'unsafe-inline'을 허용하는 대신 nonce(일회용 숫자) 또는 해시를 사용하세요.
Nonce 접근 방식: 요청마다 임의의 nonce를 생성하고 CSP 헤더에 추가한 후 스크립트 태그에 포함하세요.
Content-Security-Policy: script-src 'nonce-abc123'<script nonce="abc123">...</script>해시 접근 방식: 인라인 스크립트의 SHA 해시를 계산하여 정책에 추가하세요.
Content-Security-Policy: script-src 'sha256-xyz...'해시는 자주 변경되지 않는 정적 인라인 스크립트에 가장 적합합니다. Nonce는 동적 콘텐츠에 더 좋습니다.
스타일의 경우 nonce나 해시를 사용할 수도 있지만, nonce가 있는 style-src는 인라인 스타일 속성(예: style="...")을 포함하지 않는다는 점에 유의하세요. 이를 위해서는 'unsafe-inline'이 필요하거나 클래스로 리팩터링해야 합니다.
일반적인 CSP 지시문과 그 영향
| 지시문 | 제어 대상 | 일반적인 소스 |
|---|---|---|
| default-src | 모든 리소스 유형에 대한 대체 | 'self', https: |
| script-src | JavaScript 소스 | 'self', 'nonce-...', 'sha256-...', https://cdn.com |
| style-src | CSS 소스 | 'self', 'unsafe-inline', 'nonce-...' |
| img-src | 이미지 소스 | 'self', data:, https://images.com |
| connect-src | AJAX, WebSocket, fetch | 'self', https://api.com |
| font-src | 웹 글꼴 | 'self', https://fonts.gstatic.com |
| frame-src | Iframe | 'self', https://youtube.com |
정책을 구축할 때 이 표를 빠른 참조로 사용하세요.
CSP 테스트 및 모니터링
적용하기 전에 철저히 테스트하세요. 브라우저 개발자 도구를 사용하세요: Console 탭은 CSP 위반을 오류로 표시합니다. Network 탭은 CSP 헤더를 표시합니다.
자동화된 테스트를 위해 Google의 CSP Evaluator(온라인) 또는 csp_evaluator npm 패키지와 같은 도구를 고려하세요. 이러한 도구는 취약한 정책을 식별하는 데 도움이 됩니다.
프로덕션에서 위반을 수집하기 위해 보고 엔드포인트를 설정하세요. Report URI와 같은 서비스를 사용하거나 파일이나 데이터베이스에 로그를 기록하는 자체 엔드포인트를 구축할 수 있습니다. 새로운 문제를 포착하기 위해 정기적으로 보고서를 분석하세요.
기억하세요: CSP는 만능 해결책이 아닙니다. 방어 계층 중 하나입니다. 입력 유효성 검사, 출력 인코딩 및 기타 보안 모범 사례와 결합하세요.
FAQ
Content-Security-Policy와 Content-Security-Policy-Report-Only의 차이점은 무엇인가요?
적용 헤더(Content-Security-Policy)는 위반을 차단합니다. 보고 전용 헤더(Content-Security-Policy-Report-Only)는 차단하지 않고 위반만 보고하므로 정책을 안전하게 테스트할 수 있습니다.
onclick과 같은 인라인 이벤트 핸들러와 함께 CSP를 사용할 수 있나요?
아니요, 인라인 이벤트 핸들러는 'unsafe-inline'을 사용하지 않는 한 CSP에 의해 차단됩니다(권장되지 않음). 또는 addEventListener를 사용하도록 리팩터링하세요. 더 나은 보안을 위해 인라인 이벤트 핸들러를 피하세요.
CSP로 Google Analytics를 허용하려면 어떻게 해야 하나요?
script-src 및 connect-src 지시문에 Google Analytics 도메인을 추가하세요. 예: script-src 'self' https://www.googletagmanager.com; connect-src 'self' https://www.google-analytics.com. 최신 요구 사항은 Google 문서를 확인하세요.
CSP 배포가 고통스러운 과정일 필요는 없습니다. 점진적인 접근 방식으로 사이트를 방해하지 않고 사용자를 XSS 및 기타 공격으로부터 보호할 수 있습니다. 보고 전용 모드로 시작하고, 위반을 수정하고, 시간이 지남에 따라 정책을 강화하세요.
CSP 보고서용 JSON 구성 파일을 빠르게 포맷하거나 검증해야 하는 경우, JSON Formatter를 사용하여 JSON 데이터를 보기 좋게 만들고 디버그하세요.