콘텐츠 보안 정책에서 보고 전용 모드와 강제 적용 모드가 다른 이유

By Mirko Peters · 2026-04-23

웹 보안을 진지하게 생각한다면, 콘텐츠 보안 정책(CSP)의 '보고 전용' 모드와 '강제 적용' 모드의 차이를 이해하는 것은 사소한 세부 사항이 아니라 핵심입니다. …

Automatically translated with AI from the original post. Read the English original

웹 보안을 진지하게 생각한다면, 콘텐츠 보안 정책(CSP)의 '보고 전용' 모드와 '강제 적용' 모드의 차이를 이해하는 것은 사소한 세부 사항이 아니라 승패를 가르는 핵심입니다. 보고 전용 모드는 정책에 따라 무엇이 차단될지를 실제로 아무것도 막지 않고 확인하게 해 주므로, 웹사이트를 일종의 보안 테스트 공간으로 만들어 줍니다. 반면 강제 적용 모드는 장난으로 넘길 수 없습니다. 정책을 위반하는 모든 요청을 차단하여 실시간으로 사이트를 잠가 버립니다.

이 글에서는 두 모드가 중요한 이유, 브라우저와 사용자 경험에 미치는 영향, 단순한 모니터링에서 실질적인 보호로 전환하는 방법을 자세히 살펴봅니다. 특히 CSP 설정을 제대로 갖추려는 Microsoft 기반 보안 전문가와 개발자를 대상으로 하며, 정의, 실무 기법, 그리고 안전한 롤아웃과 효율적인 규정 준수를 위한 모범 사례를 다룹니다.

CSP 모드의 이해와 그 영향

CSP 헤더를 설정하기 전에, CSP의 두 가지 주요 모드인 보고 전용과 강제 적용을 정확히 이해해야 합니다. 이 두 모드는 단순한 설정 값이 아니라, 최신 브라우저가 웹 애플리케이션의 보안 경계를 어떻게 보호할지(또는 단순히 관찰만 할지)를 결정합니다. 어떤 모드를 선택하느냐에 따라 사이트의 위험 수준, 감사 역량, 롤아웃의 원활함이 직접적으로 달라지며, 특히 대규모 Microsoft 환경이나 멀티 클라우드 구성에서는 그 영향이 더 큽니다.

CSP 모드는 웹 팀에 유연성을 주기 위해 설계되었습니다. 보고 전용 모드는 부드러운 시작점으로, 사용자에게 문제를 일으킬지 걱정하지 않고 문제를 모니터링할 수 있게 해 줍니다. 위험 평가를 지원하고, 정책의 공백을 찾아내며, 레거시 코드나 예상치 못한 서드파티 동작을 식별하는 데 도움을 주면서도 애플리케이션은 완전히 정상적으로 운영됩니다.

강제 적용 모드가 핵심입니다. 브라우저가 지시 사항을 실제로 수행하도록 합니다. 콘텐츠가 정책과 일치하지 않으면 즉시 차단되어, 크로스 사이트 스크립팅이나 악성 서드파티 스크립트와 같은 공격 표면을 바로 줄여 줍니다. 다만 테스트와 도입에 주의를 기울이지 않으면, 실수나 불완전한 정책이 애플리케이션을 중단시킬 수 있다는 뜻이기도 합니다.

두 CSP 모드를 함께 두는 이유는 간단합니다. 개발자와 보안 팀이 완전한 강제 적용으로 넘어가기 전에 실제 환경에서 규칙을 다듬을 수 있게 하는 것입니다. 애플리케이션 보안을 위한 보조 바퀴라고 생각하되, 완전한 강제 적용으로 넘어가는 결승선이 있다고 보면 됩니다. 다음으로, 보고 전용 모드가 실제 환경의 피드백을 어떻게 제공하는지, 그리고 강제 적용이 도입되면 무엇이 달라지는지 자세히 살펴보겠습니다.

Content-Security-Policy-Report-Only가 위반 보고를 처리하는 방식

보고 전용 모드는 경기장에 들어서기 전에 관중석에서 지켜보는 방식입니다. Content-Security-Policy-Report-Only HTTP 헤더를 사용하면 브라우저에 "위반을 감시하되 아무것도 차단하지 말고 보고만 하라"고 지시하는 것입니다. 이렇게 하면 지정한 엔드포인트로 위반 보고서가 계속 전달되어, 정책이 강제 적용되었을 때 무엇이 차단될지에 대한 전체 내역을 확인할 수 있습니다.

브라우저는 리소스가 CSP 규칙을 위반할 때마다 이러한 위반 보고서(주로 JSON 페이로드 형태)를 전송합니다. 예를 들어 페이지가 승인되지 않은 출처에서 스크립트를 불러오려고 하면, 보고 전용 모드에서는 스크립트가 차단되지 않습니다. 대신 경고를 받게 되며, 문제가 된 URL, 위반된 지시어, 경우에 따라서는 의심스러운 코드의 일부 같은 세부 정보를 확인할 수 있습니다.

이 모드는 위험 평가와 안전한 테스트에 매우 유용합니다. 여러 웹 앱에 걸쳐 새 규칙을 배포하고, 어떤 규칙이 트리거되는지 모니터링하며, 추측이 아닌 실제 데이터를 기반으로 정책을 조정할 수 있습니다. 레거시 시스템을 운영하거나 미션 크리티컬한 업무 프로세스를 다루고 있다면, 너무 빠르게 진행해 사이트 중단이나 지원 요청을 겪을 위험이 없습니다.

보고 전용 모드는 점진적인 롤아웃도 지원합니다. 처음에는 느슨하게 시작해 조정이 필요한 부분을 확인한 뒤, 단계적으로 보안을 강화해 나갈 수 있습니다. 강제 적용으로 인해 극적인 장애가 발생하기 전까지는 드러나지 않았을 서드파티 스크립트, CDN 콘텐츠, 난독화된 JavaScript 관련 문제도 미리 발견할 수 있습니다. 또한 규정 준수 측면에서도 유리합니다. 조직이 적극적으로 모니터링하고 있다는 증거를 확보하게 되므로, 감사에서 상당한 주의(due diligence)를 입증해야 할 때 도움이 됩니다.

강제 적용 모드가 보안을 강화하는 방식

강제 모드는 CSP 정책이 권고에 그치지 않고 규칙이 되는 단계입니다. Content-Security-Policy 헤더를 사용하면 브라우저는 지시문과 일치하지 않는 콘텐츠를 경고 없이 실제로 차단합니다.

이 모드를 적용하면 XSS나 무단 스크립트 삽입 같은 공격에 대한 웹 애플리케이션의 방어력이 크게 높아집니다. 다만 주의가 필요합니다. 정책이 아직 실사용 수준에 이르지 않았다면 필요한 리소스가 실수로 차단되어 사이트 기능이 깨질 수 있습니다. 따라서 보고 전용 모드에서 먼저 테스트하는 것이 현명합니다. 결국 강제 모드는 이론상의 정책을 실질적인 보호로 바꾸어 주며, 강력한 웹 보안의 표준이 되는 방식입니다.

report-uri 및 report-to 엔드포인트로 보고 구성하기

보고를 설정하면 CSP 정책이 실질적인 효과를 발휘하고, 정책 위반을 살펴볼 수 있는 눈도 갖추게 됩니다. CSP에서는 report-uri 또는 report-to를 사용해 브라우저가 위반 보고서를 보낼 엔드포인트를 하나 이상 지정할 수 있습니다. 위반이 발생하면 브라우저는 차단된 리소스와 실패한 정책 같은 세부 정보를 JSON 또는 HTTP POST 메시지로 정리해 엔드포인트에 전송합니다.

report-uri 지시문은 기존 방식으로, URL을 지정하면 브라우저가 그 주소로 보고서를 직접 보냅니다. 반면 report-to는 최신 방식으로, 특히 브라우저의 Reporting API 지원이 확대되면서 더 유연하고 강력한 선택지입니다. report-to는 이름이 지정된 그룹과 함께 동작하여 다양한 유형의 보고서를 처리할 수 있고, 필터링을 더 세밀하게 제어할 수 있습니다.

이러한 엔드포인트를 구성할 때는 보안을 갖추어야 합니다. HTTPS 적용, 접근 제어, 그리고 예기치 않은 급증을 감시하는 모니터링이 필요합니다. 급증은 공격이나 잘못된 정책을 의미할 수 있습니다. 또한 개인정보 보호도 잊지 마십시오. 보고서에는 URL이나 문제가 된 스크립트의 일부가 포함될 수 있으므로, 저장하거나 공유하기 전에 민감한 정보를 제거할 준비가 되어 있어야 합니다. 이때 GDPR과 CCPA 같은 규정도 염두에 두어야 합니다.

이 방식의 진가는 가시성에 있습니다. 보고를 올바르게 구성하면 정책이 어디에서 위반을 잡아내는지 실시간으로 확인할 수 있으므로, 예상치 못한 문제 없이 조정하고 세밀하게 다듬은 뒤 안전하게 강제 모드로 전환할 수 있습니다. 단일 앱을 관리하든 규모가 큰 Microsoft 365 환경을 관리하든, 이 수준의 모니터링은 필수입니다.

효과적인 정책 설계를 위한 CSP 구문과 지시문 살펴보기

견고한 CSP 헤더를 작성하는 것이 어려운 일은 아니지만, 세부 사항에 주의를 기울여야 합니다. 특히 복잡한 앱과 Microsoft 클라우드 통합을 함께 다룰 때는 더욱 그렇습니다. 기본적으로 CSP 정책은 브라우저에 무엇이 허용되고 무엇이 허용되지 않는지 알려 주는 지시문의 구조화된 목록입니다. 이 정책은 주로 Content-Security-Policy 또는 Content-Security-Policy-Report-Only 같은 HTTP 헤더로 전달되며, 세미콜론으로 구분된 규칙 문자열 형태를 사용합니다.

정책의 핵심은 default-src, script-src, img-src 같은 주요 지시문에 있습니다. default-src는 기본값 역할을 합니다. 특정 유형의 콘텐츠에 전용 규칙이 없으면 브라우저는 이 규칙을 확인합니다. script-src와 img-src는 각각 스크립트와 이미지를 대상으로 하며, 신뢰할 수 있는 출처를 엄격하게 제어할 수 있게 해 줍니다. 자사 도메인, 신뢰할 수 있는 CDN, 그리고 Microsoft Azure Blob 저장소 한두 곳 등이 여기에 해당할 수 있습니다.

구문은 중요합니다. 각 지시문에는 허용되는 값이 나열됩니다. URL, ‘https:’ 같은 스킴, 또는 ‘self’ 같은 키워드가 올 수 있습니다. 레거시 코드에서 인라인 스크립트가 필요한 경우 ‘unsafe-inline’을 사용해야 할 수도 있지만, 이는 보호 수준을 낮춘다는 점에 유의해야 합니다. 추가 검증을 위해 스크립트 해시나 nonce를 사용하지 않는다면 특히 그렇습니다.

Microsoft 환경을 다루는 전문가라면 클라우드 서비스가 종속 요소를 어떻게 주입하는지 주의해서 살펴보아야 합니다. 복잡한 엔터프라이즈 앱은 에셋을 동적으로 로드하거나, 서비스 워커를 사용하거나, 타사 공급자를 통합하는 경우가 많습니다. 정책은 보안을 위해 엄격해야 하면서도, 앱이 정상적으로 동작할 만큼 유연해야 합니다. 처음부터 기본을 제대로 갖추어 두면 이후 테스트가 훨씬 수월해집니다.

보고 전용 모드에서 강제 모드로 전환하기 위한 모범 사례

CSP를 다루는 가장 현명한 방법은 보고 전용 모드로 시작해 데이터를 수집한 뒤에 강제 적용을 켜는 것입니다. CSP 배포를 한 번에 끝나는 체크리스트로 여기지 마십시오. 대신 정책을 모니터링하고, 조정하고, 점진적으로 강화해 나가는 단계적 프로젝트로 접근해야 최종 사용자나 업무에 중요한 워크플로가 중단되는 일을 피할 수 있습니다.

먼저 광범위하지만 합리적인 정책을 보고 전용 모드로 배포하십시오. 위반 보고서를 수집하고, 가능하면 대시보드나 분석 도구로 집계하여 반복적으로 위반하는 항목을 파악하십시오. 이렇게 하면 잡음을 걷어내고 오탐을 걸러내어 실제 위험에 집중할 수 있습니다. 일상적이거나 중복된 보고서가 많다면(흔히 그렇습니다) 로그 분석을 조정하거나, 사용자 에이전트나 리소스 유형을 기준으로 스크립트 필터를 만드십시오.

위반 건수가 줄고 대부분의 문제가 해결되면, 새로운 오류를 계속 모니터링하면서 규칙을 점진적으로 적용하기 시작하십시오. 위험도는 높지만 트래픽이 적은 영역을 먼저 적용하고 모니터링하십시오. 문제없이 진행되면 나머지 프로젝트로 범위를 넓히십시오. 전 과정에서 변경 사항을 문서화하고 개발자와 이해관계자의 피드백을 받으십시오. 특히 조건부 액세스 계층이 추가로 복잡성을 더하는 Microsoft 365나 Azure 앱에서는 더욱 그렇습니다. 관련 전략과 롤아웃 계획은 조건부 액세스 신뢰 문제에 관한 이 가이드와 이 ID 보안 에피소드를 참고하시면 좋습니다.

테스트는 절대 과소평가하지 마십시오. 브라우저 개발자 도구, CSP 상태 테스터, 심지어 자동화된 CI/CD 검사를 사용하여 정책이 의도대로 작동하는지 확인하십시오. 최종 목표는 실제 환경에서 다듬어진 정책으로 보호되어, 잠겨 있고 규정을 준수하며 복원력 있는 애플리케이션을 만드는 것입니다. 막연한 기대가 아니라 실제 검증에 기반해야 합니다.

보고 전용 모드와 적용 모드에서의 CSP 실제 예시

실제 예시만큼 CSP를 이해하기 쉽게 보여주는 것은 없습니다. 보고 전용 모드에서는 다음과 같은 헤더를 사용할 수 있습니다: Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://csp-report.example.com. 이 설정은 모든 위반 사항을 기록하면서도 사용자에게는 영향을 주지 않으므로, 위험 부담 없이 프로덕션 환경에서 테스트하기에 적합합니다.

이와 대조적으로 적용 정책은 다음과 같습니다: Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; img-src 'self'; report-uri https://csp-report.example.com. 이제 브라우저는 규칙에 맞지 않는 스크립트나 이미지를 능동적으로 차단하여, 승인되지 않은 콘텐츠로부터 사용자를 즉시 보호합니다.

실제로 조직들은 보고 전용 모드에서 시작하여, 엄격한 잠금 정책을 적용했을 때 어떤 공급업체, 스크립트, 또는 비즈니스 기능이 문제를 일으킬지 파악합니다. 예를 들어 정부 포털 웹사이트에서는 레거시 스크립트나 마케팅 분석 CDN이 반복적인 위반을 유발한다는 사실을 발견할 수 있습니다. 이후 이들은 안전한 공급업체를 허용 목록에 추가하며 반복 개선하고, 완성된 정책을 단계적으로 적용하여 업무 중단을 최소화합니다.

보고 전용에서 적용 모드로 전환하면 숨겨진 함정이 드러날 수 있습니다. 특히 타사 스크립트나 동적 콘텐츠에서 그렇습니다. 팀들은 특정 브라우저나 특정 조건에서만 나타나는 '유령' 위반을 자주 마주칩니다. 보고 전용 단계에서 수집한 실시간 데이터를 활용해 정책을 조정하면, 적용 모드가 안전할 뿐 아니라 관련된 모든 사람에게 안정적으로 작동하게 됩니다.

보고 전용 모드와 적용 모드의 주요 차이점 요약

• 동작: 보고 전용 모드는 정책 위반을 보고만 하며, 어떤 콘텐츠도 차단하지 않습니다. 적용 모드는 CSP 정책을 위반하는 모든 항목을 능동적으로 차단합니다.
• 목적: 보고 전용 모드는 사용자에게 위험을 주지 않으면서 정책을 테스트하고 조정할 수 있게 합니다. 적용 모드는 실질적인 보호를 위한 것으로, 보안 규칙을 실제로 작동하게 만듭니다.
• 사용자에 대한 영향: 보고 전용 모드는 사용자가 전혀 알아채지 못하는 방식으로 동작합니다. 적용 모드는 규칙을 사전에 테스트하지 않았다면 기능이나 콘텐츠를 깨뜨릴 수 있습니다.
• 사용 사례: 보고 전용 모드는 점진적 롤아웃, 위험 분석, 레거시 호환성 점검에 이상적입니다. 적용 모드는 견고하고 규정을 준수하는 보안을 달성하기 위한 최종 단계입니다.
• 규정 준수 & 위험: 보고 전용 모드는 감사 중 모니터링과 문서화에 도움이 되며, 적용 모드는 실시간으로 보안 침해를 직접 차단합니다.