CSP Report-Only를 운영 중단 없이 도입하는 단계별 점검법

CSP는 처음부터 차단 모드로 켜는 기능이 아니라 관찰 가능한 정책으로 시작해야 합니다. Content-Security-Policy-Report-Only 헤더로 예상 위반을 수집하고, 필수 스크립트·인라인 코드·외부 도메인을 분류한 뒤 차단 정책으로 전환하면 기존 화면을 멈추지 않고 XSS 방어 범위를 넓힐 수 있습니다.

W3C Content Security Policy Level 3는 정책을 보고만 하는 Report-Only 전달 방식과 실제 적용 방식을 구분합니다. 보고서 수집은 취약점이 모두 제거됐다는 증명이 아니므로, 수집·분류·수정·재검증의 순환으로 운영해야 합니다.W3C CSP Level 3

정책 초안은 보호할 자원을 기준으로 씁니다

먼저 페이지가 실제로 불러오는 script, style, font, image, connect 대상을 개발자 도구와 서버 템플릿에서 확인합니다. ‘모든 것을 허용하고 나중에 줄이기’보다 nonce 또는 해시를 쓸 수 있는 인라인 코드와 신뢰할 외부 출처를 구분하는 편이 수정 목록을 작게 만듭니다. Report-Only는 실행을 막지 않으므로 초기 배포는 사용자 흐름을 관찰하는 단계입니다.

• 정책 대상과 보고서 수신 엔드포인트를 분리해 개인정보가 포함되지 않는지 확인합니다.

• 위반 출처가 실제 필수 자원인지, 브라우저 확장이나 테스트 도구의 오탐인지 분류합니다.

• 수정 전후 동일한 사용자 흐름에서 보고서 수와 콘솔 오류를 비교합니다.

샘플: 결제 페이지의 외부 분석 스크립트

샘플 입력은 결제 페이지에서 분석 스크립트와 결제 API가 각각 다른 도메인에 연결되는 상황입니다. 결정은 분석 출처를 script-src에 무조건 추가하지 않고, 실제 호출 경로를 확인해 script-src와 connect-src를 각각 허용하는 것입니다. 중간 산출물은 페이지별 자원 목록과 위반 보고서 분류표입니다. 예상 결과는 결제 성공 흐름에서 새 CSP 콘솔 오류가 없고, 필요 없는 출처는 정책에 남지 않는 것입니다.

차단 전환과 실패 복구

실패 사례는 보고서에 자주 보인 출처를 검토 없이 허용 목록에 추가하는 것입니다. 그러면 정책은 길어지지만 공격 표면은 줄지 않습니다. 또 차단 모드에서 결제나 로그인 화면이 깨질 수 있습니다. 복구는 직전 정책을 되돌려 서비스 흐름을 살리고, 차단된 자원과 적용된 페이지를 함께 확인한 뒤 최소 출처 또는 nonce를 수정하고 다시 Report-Only로 재현하는 방식입니다.

완료 조건을 숫자보다 관찰로 정의합니다

1. 대표 페이지와 로그인·결제 흐름에서 자원 목록을 고정합니다.

2. 반복되는 실제 위반마다 수정 또는 예외 사유를 기록합니다.

3. 차단 전환 뒤 핵심 흐름을 재현하고 CSP 오류와 서버 지표를 확인합니다.

완료 조건은 헤더가 배포된 때가 아니라, 차단 모드에서 승인된 사용자 흐름이 재현되고 예외 출처마다 근거가 기록되며 롤백할 직전 정책이 보존된 때입니다.