CSP 운영 가이드: Report-Only부터 디버깅까지

Content-Security-Policy(CSP)는 XSS(스크립트 삽입) 피해를 크게 줄여주는 강력한 안전장치지만, 한 번에 강하게 걸면 서비스가 바로 깨질 수 있습니다.

이 문서는 CSP를 운영에 도입하는 현실적인 순서(Report-Only → 점진 강화)와 디버깅 방법을 정리합니다.

관련 용어: Content-Security-Policy (CSP), Subresource Integrity (SRI)

1) 안전한 도입 순서(권장)

1. 먼저 Report-Only로 걸기
2. 브라우저 콘솔/리포트를 보고 “필요한 출처만” 허용
3. 정책이 안정되면 Content-Security-Policy로 전환(강제)

Report-Only 예시

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; report-to csp-endpoint;

리포팅은 운영 시스템에 맞게(report-to 또는 report-uri) 선택하세요.

2) 브라우저 콘솔 에러 읽는 법

콘솔 메시지는 대부분 아래 형태입니다.

• “어떤 리소스가”
• “어떤 디렉티브에 의해”
• “왜 차단되었는지”

예: script-src에서 외부 스크립트가 막혔다면,

• 해당 스크립트를 정말 허용해야 하는지 먼저 판단하고
• 필요하다면 정확한 출처만 추가합니다.

3) unsafe-inline을 피하는 현실적인 방법

가능하면 아래 순서를 권장합니다.

1. 인라인 스크립트 제거(외부 파일로 이동)
2. 불가피하면 nonce 기반 허용
3. 정말 불가피할 때만 unsafe-inline을 임시로 사용

4) Google Analytics/Tag Manager를 쓰는 경우

GA/GTAG를 쓸 때는 보통 다음 출처가 필요합니다(서비스에 맞게 최소화).

• script-src: https://www.googletagmanager.com
• connect-src: https://www.google-analytics.com 또는 https://www.googletagmanager.com
• img-src: https:(비콘), data:
• style-src: 구글 폰트를 쓰면 https://fonts.googleapis.com
• font-src: https://fonts.gstatic.com

외부 리소스는 “필요한 도메인만” 허용하고, 전체 https: 허용은 마지막 수단으로 두세요.

5) 최소 체크리스트

• CSP는 보안장치일 뿐, 취약점 자체를 없애지 않습니다(입력 검증/출력 이스케이프가 우선).
• default-src 'self'로 시작해, 필요한 것만 추가합니다.
• 정적 사이트는 상대적으로 CSP 도입이 쉬운 편입니다(스크립트 출처가 단순).
• 운영에서는 반드시 Report-Only로 워밍업하세요.

같이 보면 좋은 문서:

• nginx: 보안 헤더 기본 세트(CSP 포함)
• Content-Security-Policy (CSP)