AI 생성웹사이트 운영자라면 CSP부터 점검하세요 — XSS 피해를 줄이는 보안 헤더 사용법

🤖 AI 생성 콘텐츠 — 이 글은 AI가 자료를 수집하고 초안을 작성했으며, 발행 전 누슘 운영자가 검수했습니다.

CSP는 브라우저가 불러오고 실행할 스크립트·이미지·프레임의 출처를 서버가 제한해 XSS 피해 범위를 줄이는 웹사이트 다층 방어용 보안 정책이다.

사이트에 악성 스크립트가 들어왔다고 해봅시다. 입력 검증이 첫 번째 문이라면, CSP는 건물 안쪽의 방화문입니다. 첫 문이 뚫렸더라도 공격 코드가 아무 서버에서나 자원을 불러오거나 마음대로 실행하지 못하게 범위를 좁힙니다.

목차

• CSP는 어떻게 동작하나
• 처음부터 차단하면 왜 사고가 나나
• 실무에서 어떤 정책으로 시작할까

CSP는 어떻게 동작하나?

서버는 HTTP 응답에 Content-Security-Policy 헤더를 보냅니다. 브라우저는 헤더의 지시문을 읽고 허용되지 않은 자원 로드와 실행을 막습니다. W3C CSP Level 3 초안은 페이지가 가져오거나 실행할 자원과 여러 보안 결정을 제어하는 메커니즘으로 CSP를 정의합니다.

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'

처음부터 차단하면 왜 사고가 나나?

기존 사이트에는 분석 스크립트, 결제 위젯, 글꼴, 이미지 CDN처럼 외부 자원이 많습니다. 정책을 곧바로 강제하면 정상 기능까지 막힐 수 있습니다. 이때 쓰는 것이 Content-Security-Policy-Report-Only 헤더입니다. 차단 대신 위반을 관찰해 정책을 다듬을 수 있습니다.

W3C 문서는 Report-Only를 정책을 반복적으로 배포하기 위한 장치로 설명합니다. 다만 meta 요소 안에서는 Report-Only 헤더가 지원되지 않습니다. 가능하면 서버 응답 헤더로 관리하는 편이 명확합니다.

주의할 점도 있습니다. 출처 목록을 너무 넓게 열거나 'unsafe-inline'에 기대면 정책의 힘이 크게 약해집니다. 반대로 CDN 주소를 끝없이 나열하면 관리가 어려워집니다. W3C 문서의 Strict CSP 예시는 스크립트에 nonce나 해시를 쓰고, 상황에 따라 'strict-dynamic'을 조합하는 방향을 제시합니다.

실무에서 어떤 정책으로 시작할까?

다음 순서가 안전합니다.

1. 현재 로드되는 스크립트·프레임·폰트 출처를 목록화합니다.
2. Report-Only로 위반 보고를 모읍니다.
3. 인라인 스크립트를 제거하거나 요청마다 새로운 nonce를 부여합니다.
4. 핵심 페이지부터 강제 정책으로 전환합니다.
5. 새 외부 도구를 붙일 때 정책 변경을 코드 리뷰에 포함합니다.

nonce는 한 번만 쓰는 임시 통행증입니다. 응답마다 예측하기 어려운 값을 새로 만들고, 허용할 <script>와 헤더에 같은 값을 넣습니다. 같은 nonce를 재사용하면 공격자가 통행증을 훔쳐 쓸 여지가 생기므로 금물입니다.

자주 묻는 질문 (FAQ)

Q. CSP만 설정하면 XSS가 완전히 막히나요? A. 아닙니다. W3C도 CSP를 입력 검증과 출력 인코딩의 대체가 아닌 심층 방어로 설명합니다. 취약점 자체를 고치고 CSP로 피해를 줄여야 합니다.

Q. CSP는 HTML meta 태그로도 설정할 수 있나요? A. 일부 정책은 meta http-equiv로 전달할 수 있습니다. 그러나 Report-Only, frame-ancestors, sandbox 등은 meta 방식에 제약이 있어 응답 헤더가 권장됩니다.

Q. Report-Only는 실제 공격을 막나요? A. 막지 않습니다. 위반을 보고하고 관찰하는 모드라 정책을 시험하는 데 쓰며, 검증 후 강제 헤더로 전환해야 합니다.

Q. nonce는 페이지마다 같은 값을 써도 되나요? A. 안 됩니다. W3C 문서는 nonce 재사용을 보안 고려사항으로 다루며, 각 응답에서 새롭고 예측하기 어려운 값을 사용하는 것이 핵심입니다.

마치며

CSP는 화려한 기능이 아니지만 사고가 났을 때 차이를 만드는 안전벨트입니다. 우선 운영 중인 사이트의 응답 헤더를 열어 Report-Only부터 시작해보세요. 적용하면서 막힌 자원이나 예상 밖의 문제가 있었다면 누슘에서 사례를 공유해주세요.

참고자료

• W3C — Content Security Policy Level 3
• MDN — Content Security Policy

태그: #CSP #ContentSecurityPolicy #XSS #웹보안 #nonce #strictdynamic #보안헤더