콘텐츠 보안 정책에서 보고 전용 모드와 적용 모드의 차이

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의 작동 방식

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

브라우저는 리소스가 CSP 규칙을 위반할 때마다 이 위반 보고서를 전송합니다(대개 JSON 페이로드 형태입니다). 예를 들어 페이지가 승인되지 않은 출처에서 스크립트를 로드하려고 하면, 보고 전용 모드에서는 어떤 스크립트도 차단되지 않습니다. 하지만 문제가 된 URL, 위반된 지시문, 때로는 의심스러운 코드의 일부 같은 세부 정보와 함께 알림을 받게 됩니다.

이 모드는 위험 평가와 안전한 테스트에 매우 유용합니다. 여러 웹 앱에 걸쳐 새 규칙을 배포하고, 어떤 규칙이 트리거되는지 모니터링한 다음, 추측이 아닌 실제 데이터를 기반으로 정책을 조정할 수 있습니다. 레거시 시스템을 운영하거나 업무상 핵심적인 워크플로가 있다면, 너무 서두르다가 사이트 장애나 지원 문의가 발생하는 위험을 피할 수 있습니다.

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

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

강제 모드(Enforced mode)는 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 배포를 한 번에 끝나는 체크리스트로 여기지 마십시오. 대신 모니터링하고 조정하면서 정책을 단계적으로 강화해 나가는 단계별 프로젝트로 접근해야 합니다. 그래야 최종 사용자나 업무에 중요한 워크플로가 중단되는 일을 피할 수 있습니다.

먼저 보고 전용 모드로 합리적인 범위의 정책을 폭넓게 적용하세요. 위반 보고서를 수집하고, 가능하면 대시보드나 분석 도구로 집계해 반복적으로 발생하는 위반 주체를 찾아내는 것이 좋습니다. 이렇게 하면 노이즈를 걸러내고 잘못된 양성(false positive)을 제외해 실제 위험에 집중할 수 있습니다. 일상적이거나 중복된 보고서가 많다면(흔히 그렇습니다) 로그 분석을 조정하거나 사용자 에이전트, 리소스 유형을 기준으로 스크립트 필터를 추가하세요.

위반 건수가 줄고 대부분의 문제가 해결되면 새 위반이 발생하는지 계속 모니터링하면서 규칙을 단계적으로 적용하세요. 위험도는 높지만 트래픽이 적은 영역부터 적용해 관찰합니다. 문제없이 진행되면 나머지 프로젝트로 확대하세요. 전 과정에서 변경 사항을 문서화하고 개발자와 이해관계자의 피드백을 받으세요. 특히 조건부 액세스 계층이 추가로 얽혀 있는 복잡한 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 정책을 위반하는 모든 항목을 능동적으로 차단합니다.
• 목적: 보고 전용 모드는 사용자에게 위험을 주지 않으면서 정책을 테스트하고 조정할 수 있게 합니다. 적용 모드는 실제 보호를 위한 것으로, 보안 규칙을 실질적인 효력이 있게 만듭니다.
• 사용자 영향: 보고 전용 모드는 사용자가 전혀 인식하지 못하는 상태로 동작합니다. 적용 모드는 규칙을 사전에 테스트하지 않았다면 기능이나 콘텐츠를 망가뜨릴 수 있습니다.
• 사용 사례: 보고 전용 모드는 단계적 배포, 위험 분석, 레거시 호환성 점검에 이상적입니다. 적용 모드는 견고하고 규정을 준수하는 보안을 달성하기 위한 최종 단계입니다.
• 규정 준수 & 위험: 보고 전용 모드는 감사 중 모니터링과 문서화에 도움이 되는 반면, 적용 모드는 실시간으로 보안 침해를 직접 차단합니다.