CSP Report-Only 보고서로 정책을 다듬는 순서

Content-Security-Policy-Report-Only는 정책 위반을 관찰하고 보고하도록 설계된 헤더이며, 해당 정책으로 리소스를 차단하지 않습니다. 수집된 보고가 곧 공격이나 정책 위반 확정이라는 뜻도 아닙니다.

보고를 받으려면 CSP 보고 지시자와 수신 경로를 구성해야 합니다. 출처·브라우저별 차이와 보고 데이터의 개인정보를 검토하고, 정책을 실제 강제하기 전에는 합법적 기능을 충분히 시험해야 합니다.

관찰 모드와 차단 모드를 혼동하지 않습니다

강제 정책 헤더 Content-Security-Policy는 정책에 어긋나는 리소스 로드를 제한합니다. 반면 Content-Security-Policy-Report-Only는 정책을 위반해도 그 정책으로 차단하지 않고 보고를 보낼 수 있게 합니다. 따라서 보고 전용 헤더가 응답에 있다는 사실만으로 공격이 막혔다고 말할 수 없습니다. 브라우저가 실제로 강제하는 다른 CSP 헤더가 별도로 있을 수 있으므로, 응답의 모든 CSP 헤더를 살펴야 합니다.

가상 보고 건을 세 부류로 나눕니다

브라우저 보고서 하나만으로 악성코드나 침해라고 확정하지 않습니다. 개발자 도구의 네트워크 기록, 릴리스 변경 사항, 기능 소유자 확인과 함께 보아야 합니다. 같은 URL이 반복돼도 사용자·브라우저·화면이 하나에 몰려 있으면 전체 사용자 영향으로 확대할 수 없습니다.

보고서 수신 경로와 데이터 취급도 설계입니다

보고 헤더에 수신 경로를 지정하지 않으면 기대한 보고가 도착하지 않을 수 있습니다. CSP 문서는 report-to를 안내하며, 호환성을 위해 기존 report-uri를 함께 두는 구성이 아직 필요한 환경도 있습니다. 보고 전달은 브라우저 지원과 응답 정책에 따라 달라지므로 운영 브라우저에서 검증하세요. URL, 페이지 경로, 사용자 입력 조각이 보고서에 포함될 수 있으니 수집 최소화, 접근 제한, 보존 기간과 외부 전송 여부도 점검합니다.

관찰에서 강제로 옮길 때의 실천 순서

1. 현재 응답의 강제 CSP와 Report-Only CSP를 각각 저장합니다.
2. 보고 지시자와 수신 endpoint가 구성됐는지 테스트 환경에서 확인합니다.
3. 정상 기능의 대표 화면·브라우저를 정해 Report-Only를 관찰합니다.
4. 보고를 페이지 기능, 배포 변화, 출처, 반복 빈도로 묶어 분류합니다.
5. 정책 누락 후보는 담당 기능과 원래 의도를 확인하고, 잡음은 근거를 남깁니다.
6. 누락 정책을 수정한 뒤 정상·오류 경로를 다시 시험합니다.
7. 강제 전환은 영향 범위와 되돌림 계획을 승인받고 단계적으로 진행합니다.

보고 수가 줄었다고 정책이 안전하다는 뜻은 아닙니다

보고가 없으면 수신 설정, 브라우저 호환, 트래픽 표본이 부족한 것일 수 있습니다. 반대로 보고가 많으면 공격이 많다는 뜻일 수도 있지만, 정책이 애플리케이션 기능과 맞지 않거나 브라우저 확장 보고가 섞였을 수 있습니다. 수집 품질과 차단 상태를 별도의 지표로 관리해야 합니다.

복습: Report-Only가 막아 주나요?

문제: Report-Only 헤더의 script-src 'self'와 맞지 않는 스크립트 요청 보고가 수신됐습니다. 해당 헤더 때문에 브라우저가 요청을 차단했다고 답해도 될까요?

정답: 아니요. Report-Only 정책은 보고를 위한 관찰 모드이며 그 정책 자체로 차단하지 않습니다. 응답의 별도 강제 CSP 헤더와 실제 브라우저 동작을 확인해야 합니다.