Defaults.Exposed › 수정 › 콘텐츠 보안 정책 (CSP)

콘텐츠 보안 정책 (CSP) 수정 방법

콘텐츠 보안 정책은 웹사이트가 모든 방문자의 브라우저에 전달하는 안전 규칙으로, 어떤 코드가 실행 허용되는지 정확히 지시합니다. 이 설정이 없으면 댓글 입력란, 해킹된 플러그인, 서드파티 스크립트 등을 통해 악성 코드가 페이지에 들어올 경우 브라우저가 자유롭게 실행합니다. 자물쇠가 여전히 표시되는 상태에서 고객이 입력하는 카드 번호와 비밀번호를 조용히 탈취하는 코드 실행도 포함됩니다.

비즈니스에 미치는 핵심 영향: 사이트가 변조되면 악성 코드가 모든 것이 완전히 정상으로 보이는 상태에서 귀사 결제 페이지에서 고객의 카드 정보와 로그인 정보를 직접 읽을 수 있습니다. 결과는 환불 요청, 사기 신고, 보고 의무가 있는 데이터 유출, 그리고 대형 고객사의 보안 팀이 거래를 지연시키거나 취소하는 데 사용하는 검사 실패입니다.

발생 가능한 비용

• 숨겨진 코드가 귀사 결제 페이지에 삽입되어 고객이 결제 시 입력하는 모든 카드 번호, 이름, CVV를 복사해 공격자에게 전송합니다. 사이트는 완전히 정상적으로 보이고 작동합니다. 사기 신고가 쏟아지고 나서야 알게 됩니다.
• 사기꾼이 귀사 실제 웹사이트에 가짜 '여기서 결제' 양식을 삽입합니다. 고객은 귀사 브랜드를 신뢰하며 정보를 입력하고, 돈과 데이터가 공격자에게 갑니다.
• 더 큰 잠재 고객의 보안 팀이 벤더 실사의 일환으로 자동화된 사이트 스캔을 실행합니다. 없는 콘텐츠 보안 정책이 즉시 높은 심각도 격차로 나타납니다.
• 표준적이고 무료인 안전장치가 없어 데이터 유출로 이어졌을 때 나쁜 운에서 과실로 전환됩니다.

중요한 이유. 자물쇠는 사이트 연결이 개인적임을 증명하지만 방문자가 페이지에 있는 동안 어떤 코드가 실행되는지 제어하지 않습니다. 콘텐츠 보안 정책은 그것을 수행하는 안전장치입니다. 단일 변조된 필드, 광고, 또는 플러그인이 고객의 돈과 데이터를 훔치는 도구로 전환될 수 없도록 신뢰하지 않는 소스의 스크립트를 무시하도록 브라우저에게 지시합니다.

쉬운 설명

누군가 웹사이트를 방문하면 브라우저가 페이지를 다운로드하고 그 안의 모든 코드를 실행합니다. 기본적으로 브라우저는 모든 것을 신뢰합니다. 어떤 코드가 진짜 귀사의 것이고 어떤 것이 외부인이 삽입한 것인지 알 방법이 없습니다.

콘텐츠 보안 정책(CSP)은 웹사이트가 모든 페이지에 첨부하는 규칙 목록으로, 브라우저에게 이렇게 말합니다: “이 승인된 소스의 코드만 실행하고 다른 것은 모두 거부하세요.” 손님 명단이 있는 나이트클럽과 손님 명단 없이 누구나 들어오는 나이트클럽의 차이입니다.

이것이 중요한 이유: 웹사이트는 끊임없이 변조됩니다 — 서버를 해킹하지 않고도 댓글 필드, 검색 창, 오래된 플러그인, 광고나 분석을 위한 서드파티 스크립트, 채팅 위젯을 통해 들어올 수 있습니다.

비즈니스 피해 사례

• 보이지 않는 결제 스키머. 공격자가 취약한 플러그인이나 손상된 서드파티 스크립트를 통해 결제 페이지에 몇 줄의 코드를 삽입합니다. 모든 카드 번호, 이름, CVV가 실시간으로 복사되어 공격자에게 전송됩니다. 사이트는 완전히 정상적으로 작동하고 자물쇠도 있습니다.

• 가짜 결제 양식. 사기꾼이 귀사 실제 웹사이트에 설득력 있는 “여기서 결제” 상자를 삽입합니다. 고객은 귀사 브랜드를 신뢰하며 정보를 입력하고 돈과 데이터가 공격자에게 갑니다.

• 잃어버린 계약. 더 큰 잠재 고객의 보안 팀이 벤더 실사의 일환으로 자동화된 스캔을 실행합니다. 없는 콘텐츠 보안 정책이 즉시 높은 심각도 격차로 표시됩니다.

• 보고 가능한 유출. 데이터 유출이 없는 표준적이고 무료인 안전장치로 추적될 때 나쁜 운에서 과실로 전환됩니다.

• 손상된 광고나 위젯. 많은 사이트가 외부 광고 네트워크, 폰트, 지원 채팅, 분석 코드를 로드합니다. 그 중 하나가 침해되면 악성 코드가 귀사 페이지에 직접 탑승합니다.

CSP의 실제 작동 방식

콘텐츠 보안 정책은 단일 HTTP 응답 헤더로 전달됩니다. 예를 들어:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self'

쉬운 말로: 기본적으로 내 자체 사이트의 것만 로드하고, 내 자체 사이트의 스크립트만 실행하며, 오래된 스타일 플러그인은 허용하지 말고, 다른 사이트가 내 사이트를 프레임 안에 넣지 못하게 합니다.

좋은 상태는 헤더의 존재만 확인하는 것이 아니라 정책을 지시어별로 읽고 실제로 얼마나 강한지 채점합니다:

• 제한적 기준선(default-src 'self')을 설정하고 실제로 사용하는 특정 신뢰할 수 있는 서드파티만 확장.
• 허점 회피. 스크립트에 'unsafe-inline'이나 'unsafe-eval' 사용 안 함, 스크립트에 와일드카드(*)나 기본 스키마 소스(예: https:) 사용 안 함.
• frame-ancestors 'self'로 프레이밍 제한 및 object-src 'none'으로 레거시 플러그인 비활성화.
• 시행 중, 보고만이 아님. Content-Security-Policy-Report-Only 헤더는 감시만 합니다.

수정 방법 (무료, 약 1~2시간)

IT 담당자나 웹사이트를 담당하는 사람에게 이 섹션을 전달하세요 — 수정 자체는 완전히 무료입니다.

1. 보고만 모드로 시작 — 아직 시행하지 마세요. Content-Security-Policy-Report-Only 응답 헤더를 추가합니다.

2. 사이트가 실제로 사용하는 것으로 정책 구축. 보고서를 검토해 모든 합법적인 스크립트, 스타일, 폰트, 이미지 소스를 찾습니다.

3. 전체 요점을 무너뜨리는 허점 피하기. 스크립트에 'unsafe-inline'과 'unsafe-eval', 와일드카드 소스를 피하세요.

4. 프레이밍과 플러그인 제한. frame-ancestors 'self'와 object-src 'none' 추가.

5. 보고만에서 시행으로 전환. 보고서가 깔끔하고 사이트가 작동하면 헤더 이름을 Content-Security-Policy-Report-Only에서 Content-Security-Policy로 변경합니다. 이것이 실제로 보호를 제공하는 단계입니다.

   헤더 설정 위치:

   • Cloudflare: 규칙 → Transform 규칙 → 응답 헤더 수정
   • Nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';" always;
   • Apache: Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';"

6. 도메인 재확인.

흔한 실수

• 보고만에서 멈추기. 가장 흔한 오류. 보고만은 아무것도 차단하지 않습니다. 시행으로 전환해야 합니다.
• “그냥 작동하게” 하려고 'unsafe-inline' 사용. 이것은 정책이 닫으려는 정확한 구멍을 다시 엽니다. 대신 nonce나 hash를 사용하세요.
• 와일드카드 사용. script-src의 기본 *는 어디서나 스크립트를 허용하므로 정책이 거의 실제 보호를 제공하지 않습니다.
• 서드파티 소스 잊기. 시행하기 전에 합법적인 외부 서비스를 먼저 나열하지 않으면 사이트 일부가 손상됩니다.
• 홈페이지에만 설정. 정책은 특히 결제, 로그인, 계정 페이지에 있는 모든 페이지를 커버해야 합니다.
• 자물쇠 대신으로 취급. CSP와 HTTPS/HSTS는 다른 것을 보호합니다.

FAQ