웹 MVP CSP: 보고·예외·실제 차단을 나누는 5가지 기준

웹 MVP CSP: 보고·예외·실제 차단을 나누는 5가지 기준

직접 답변: 웹 MVP에 Content Security Policy(CSP)를 도입할 때는 “정책 문자열을 작성한 상태”, “현재 페이지가 어떤 리소스를 실제로 불러오는지 기록한 상태”, “Report-Only에서 위반을 관찰한 상태”, “예외를 검토한 상태”, “실제 차단을 적용하고 핵심 흐름을 다시 확인한 상태”를 분리해야 합니다. 콘솔에 오류가 없거나 헤더가 하나 보인다는 관찰만으로 외부 스크립트·결제·분석·로그인 흐름이 모두 안전하거나 정상이라고 결론 낼 수는 없습니다.

MDN은 Content-Security-Policy HTTP 응답 헤더가 브라우저가 해당 페이지에서 불러올 수 있는 리소스를 제어한다고 설명합니다. 하지만 어떤 출처를 허용할지는 제품의 실제 의존성과 사용자 흐름을 보고 정해야 합니다. 이 글은 초기 웹 MVP가 차단 전환의 확인 순서를 세우는 방법이며, 보안 인증, 침해 방지, 심사 통과, 전환율이나 매출 향상을 보장하지 않습니다.

CSP를 “보안 완료”가 아니라 배포 상태로 기록합니다

CSP는 외부 스크립트, 이미지, 스타일, 폰트, API 연결, 폼 전송처럼 페이지가 불러오거나 이동시키는 리소스의 허용 범위를 헤더로 선언하는 방법입니다. 그래서 script-src에 한 출처를 추가했다는 작업과, 실제 결제 화면의 스크립트가 정상으로 로드됐다는 결과는 다릅니다. 같은 정책이라도 페이지별 리소스와 브라우저 조건이 다르면 관찰 결과가 달라질 수 있습니다.

초기 팀은 먼저 “어떤 화면에 어떤 헤더를 내보내는가”를 적고, 다음으로 “그 화면에서 실제로 필요한 리소스는 무엇인가”를 목록으로 분리하세요. 광고 태그, 분석 도구, 고객 채팅, 결제 위젯, 인증 SDK, 이미지 CDN을 한 줄의 ‘외부 도구’로 묶으면 필요 출처와 책임자가 흐려집니다. 반대로 목록만 길고 사용자 흐름이 없으면 가입·결제·문서 제출처럼 중요한 경로가 빠질 수 있습니다.

이 다섯 행을 분리하면 개발팀은 정책의 원인을, 운영팀은 외부 도구의 소유자를, QA는 사용자 흐름의 재시험 범위를 각자 확인할 수 있습니다.

기준 1: 화면이 아니라 리소스와 사용자 흐름을 함께 목록화합니다

새 랜딩 페이지에는 분석 스크립트만 있어도, 로그인이나 결제 페이지에는 인증 공급자·결제 위젯·API 연결·에러 수집 도구가 더해질 수 있습니다. 따라서 “운영 도메인을 허용했다”라는 말보다, 화면·기능·리소스 유형·도메인·소유자·계속 필요한 이유를 남기는 편이 다음 배포에서 검증하기 쉽습니다.

특히 인라인 스크립트나 이벤트 속성이 남아 있는 레거시 화면은 정책 전환 때 영향을 받을 수 있습니다. MDN의 실무 가이드는 가능한 한 unsafe-inline 같은 안전하지 않은 소스를 피하라고 안내합니다. 이 안내는 지금 당장 기능을 멈추라는 뜻이 아니라, 어떤 코드가 예외를 요구하는지 먼저 확인하고 제거·변경·명시적 예외 중 무엇을 택할지 기록하라는 신호로 쓰는 편이 좋습니다.

리소스 목록은 최소한 핵심 가입, 로그인, 문의, 결제, 파일 업로드처럼 실제 제공 중인 흐름에서 다시 확인하세요. 아직 제공하지 않는 기능이나 고객별 설치 도구를 가능한 것처럼 적지 말고, 확인하지 못한 환경은 미확인으로 남깁니다.

기준 2: Report-Only의 관찰과 실제 차단을 같은 성공으로 보지 않습니다

Content-Security-Policy-Report-Only는 후보 정책의 위반과 영향을 관찰하지만 그 정책을 강제하지 않는 헤더입니다. 따라서 이 단계는 실제 차단을 켜기 전, 어떤 요청이 정책과 맞지 않는지 찾는 데 쓸 수 있습니다. 다만 보고가 적다는 사실은 트래픽이 적었거나 아직 해당 사용자 흐름이 실행되지 않았기 때문일 수도 있으므로, “보고 0건”을 곧바로 안전 판정으로 바꾸지 마세요.

Report-Only를 적용할 때는 관찰 기간이라는 달력 정보만 남기지 말고, 어느 릴리스·어느 화면·어느 브라우저 조건·어느 사용자 행동에서 점검했는지도 함께 기록합니다. 예를 들어 결제 직전 화면을 검수하지 않았다면 결제 관련 외부 스크립트가 정상이라는 결론을 보류해야 합니다. 보고 내용은 진단 재료이고, 사용자 입력이나 URL 같은 값은 저장·공유 전에 민감 정보 노출 가능성을 별도 검토해야 합니다.

우리 웹 MVP의 외부 리소스와 출시 점검표 정리하기

기준 3: 보고 endpoint 설정과 보고 내용 처리를 따로 검수합니다

보고를 쓰려면 브라우저가 보낼 목적지가 있어야 합니다. MDN의 report-to 문서는 CSP의 이름과 Reporting-Endpoints 헤더에 정의한 endpoint를 연결하는 방식을 설명합니다. 즉 정책 안에 report-to라는 단어가 있다는 관찰과, 실제 endpoint가 올바르게 설정돼 보고를 받는다는 상태는 다릅니다.

새 endpoint를 만들거나 외부 수집 도구를 연결할 때는 URL, 데이터 보관 위치, 접근 권한, 보존 기간, 담당자, 장애 시 대체 행동을 운영 문서에 분리하세요. CSP 보고에는 페이지 URL이나 차단된 리소스처럼 검토가 필요한 정보가 들어갈 수 있으므로, 보고를 원본 그대로 팀 채팅이나 대시보드에 넓게 노출하는 설계를 당연시하지 않는 편이 안전합니다.

또한 report-to는 우선되는 방향으로 안내되지만 브라우저 지원은 다를 수 있습니다. MDN은 호환성을 고려해 report-uri도 함께 지정하는 예시를 제공합니다. 이것은 모든 서비스가 두 방식을 반드시 도입해야 한다는 명령이 아닙니다. 목표 브라우저, 실제 리포트 수신, 운영할 endpoint의 보안·비용 조건을 확인한 뒤 현재 릴리스의 선택과 미확인 범위를 적으세요.

기준 4: 예외를 누적하지 말고 결정 근거와 종료 조건을 남깁니다

정책 전환 중에 특정 CDN, 인라인 코드, 제휴 스크립트를 임시로 허용해야 할 수 있습니다. 이때 “오류가 사라졌다”는 이유만으로 넓은 출처 또는 unsafe-inline을 영구적으로 남기면, 다음 기능 추가 때 어떤 허용이 실제로 필요한지 판단하기 어려워집니다.

예외 하나마다 기능 이름, 대상 화면, 허용한 directive, 소유자, 근거, 검토일, 제거 또는 재검토 조건을 남겨 보세요. 예를 들어 인증 공급자가 바뀌면 기존 도메인이 더 이상 필요한지, 분석 도구를 제거하면 연결 허용이 남아 있는지 다시 봅니다. 이 기록은 특정 보안 수준을 인증하는 문서가 아니라, 현재 제품의 외부 의존과 변경 책임을 추적하는 최소 단위입니다.

Android 앱의 네트워크 통신 기본값·도메인 예외·디버그 구성을 구분해야 한다면 앱 MVP Android 네트워크 보안 구성: 기본값·도메인·디버그를 나누는 5가지 기준도 함께 참고할 수 있습니다. 연결 글은 Android 앱 설정을 다루고, 이 글은 웹 응답 헤더와 브라우저 리소스 제어의 배포 순서에 집중합니다.

기준 5: 실제 차단 뒤에는 핵심 흐름을 다시 검수합니다

Report-Only에서 관찰한 내용을 검토하고 정책을 실제 Content-Security-Policy로 전환했다면, 배포 완료라고 적기 전에 핵심 흐름을 다시 지나가야 합니다. 최소한 첫 화면, 로그인, 가입, 결제 또는 문의처럼 현재 서비스가 제공하는 중요 흐름에서 리소스 로드, 폼 제출, 오류 안내, 되돌아가기, 모바일 화면을 확인합니다. 제공하지 않는 기능은 체크리스트에서 완료로 표시하지 않습니다.

릴리스 기록에는 정책 버전, 적용한 응답 경로, 검사한 환경, 통과한 흐름, 보류한 예외, 다음 재검토 시점을 남기세요. CSP를 적용했다는 사실은 특정 응답에서 정책을 강제했다는 기술적 상태입니다. 그 자체로 XSS를 모두 제거했다는 증명, 개인정보 보호 적합성, 보안 인증, 고객 신뢰·전환·매출 증가를 뜻하지는 않습니다.

전환 전 5분 점검표

1. 화면별 외부 리소스와 담당자를 목록으로 분리했는가?

2. Report-Only에서 검사한 릴리스·흐름·환경을 기록했는가?

3. 보고 endpoint의 수신·접근·보존 책임을 확인했는가?

4. 예외마다 이유와 재검토 또는 제거 조건을 남겼는가?

5. 실제 차단 뒤 현재 제공 중인 핵심 흐름을 다시 확인했는가?

자주 묻는 질문

CSP 헤더가 보이면 보안 설정이 끝난 건가요?

아닙니다. 헤더가 보인다는 것은 해당 응답에 정책이 실려 있다는 관찰입니다. 실제 directive, 화면별 리소스, Report-Only 관찰, 예외 검토, 실제 차단 뒤 핵심 흐름 재시험은 별도로 확인해야 합니다.

Report-Only에서 위반이 없으면 바로 차단해도 되나요?

Report-Only는 후보 정책의 위반을 관찰하지만 강제하지 않습니다. 어떤 릴리스·화면·사용자 흐름·브라우저를 확인했는지 먼저 기록하고, 확인하지 못한 경로는 미확인으로 남긴 뒤 실제 서비스 범위에서 전환을 검토하세요.

report-to만 넣으면 CSP 보고가 수집되나요?

report-to는 정책에서 보고 목적지 이름을 지정하는 directive입니다. 그 이름에 대응하는 Reporting-Endpoints 설정과 실제 수신 결과를 함께 확인해야 합니다. 목표 브라우저의 지원 범위도 별도로 검토하세요.

CSP를 적용하면 개인정보 보호나 보안 인증을 증명할 수 있나요?

아닙니다. CSP는 브라우저가 허용된 리소스를 불러오도록 제어하는 한 가지 기술적 장치입니다. 개인정보 처리, 접근 권한, 서버 보안, 인증·심사 요건과 사업 성과는 각각 별도의 근거와 검토가 필요합니다.

우리 서비스의 CSP 전환 범위와 확인 기준 정리하기

출처

• MDN — Content-Security-Policy header

• MDN — Content-Security-Policy-Report-Only header

• MDN — CSP implementation guide

• MDN — CSP report-to directive