CSP 분석기는 Content-Security-Policy를 읽고 두 가지를 보여 줍니다. 첫째는 유효 정책 표입니다. 스크립트, 스타일, 이미지, 글꼴, 연결, 미디어, 프레임, 워커, 플러그인, 매니페스트와 base-uri, form-action, frame-ancestors에 대해 폴백(default-src, child-src, script-src)을 적용한 뒤, 각 리소스 종류가 실제로 무엇을 불러올 수 있는지를 차단부터 제한 없음까지의 수준으로 알려 줍니다. 둘째는 오류, 경고, 참고로 나눈 점검 목록이며 각각 개수를 세어 줍니다.
DevTools, CDN 대시보드, 리버스 프록시 설정에서 헤더를 방금 복사한 사람이 배포 전에 눈에 띄는 문제가 무엇인지 빠르게 보는 정적 점검입니다. 값만, 헤더 한 줄 전체(Content-Security-Policy-Report-Only: 포함), <meta http-equiv> 태그 중 무엇을 붙여넣어도 됩니다. 알맞은 정책은 애플리케이션이 무엇을 불러오느냐에 달려 있으므로 점수는 매기지 않습니다.
정책은 브라우저 안에서 텍스트로 분석합니다. 안에 적힌 출처에는 접속하지 않으며 값은 이 도구가 서버로 전송하지 않습니다. 결과가 깨끗하다고 정책이 안전하다는 증명은 아니고, 점검에 걸리는 것이 없었다는 뜻일 뿐입니다.
사용 방법
정책 붙여넣기
헤더 값, 헤더 한 줄 전체, 메타 태그 중 무엇이든 붙여넣습니다. 앞의 헤더 이름, 줄바꿈, 감싼 따옴표는 알아서 제거합니다. 한도는 512KiB이고 입력이 비어 있으면 오류가 표시됩니다.
요약 읽기
카운터에 오류, 경고, 참고의 개수와 정책의 지시문·소스 수가 나옵니다. 오류는 정책을 깨거나 무력화하는 문제, 경고는 정책을 약화시키는 문제, 참고는 맥락이나 모범 사례입니다.
허용 범위 확인
유효 정책 표는 리소스 종류별로 폴백을 적용한 소스, 차단부터 제한 없음까지의 수준, 값이 어느 지시문에서 왔는지를 보여 줍니다. 설정 없음으로 표시된 행은 브라우저가 아무 제한도 두지 않는다는 뜻입니다.
점검 항목 처리
항목마다 지시문 이름과 문제, 흔한 해결 방법이 나옵니다. 정책을 고친 뒤 배포된 응답을 브라우저에서 시험하세요. 먼저 report-only 헤더로 시험하는 것이 좋습니다.
작동 원리
CSP의 구조와 폴백 (CSP Level 3)
정책은 세미콜론으로 구분된 지시문의 목록입니다. 지시문은 이름과 소스 표현식으로 이루어지며, 소스에는 'self', 'none', 'nonce-...'처럼 작은따옴표로 감싼 키워드, https: 같은 스킴 소스, https://cdn.example.com이나 *.example.com 같은 호스트 소스가 있습니다. 지시문은 첫 번째 것만 적용되므로 반복은 오류로 보고합니다.
fetch 계열 지시문은 없으면 다른 지시문으로 대체되며 유효 정책 표는 정확히 이 사슬을 따릅니다. 대체되지 않는 중요한 지시문도 몇 가지 있어서, 이들이 없으면 제한이 전혀 없습니다.
| 지시문 | 대체되는 곳 | 제어 대상 |
|---|---|---|
script-src, style-src, img-src, font-src, connect-src, media-src, object-src, manifest-src | default-src | 리소스 종류별로 불러올 수 있는 출처 |
frame-src | child-src, 그다음 default-src | 임베드된 프레임 |
worker-src | child-src, script-src, 그다음 default-src | 웹 워커 |
base-uri, form-action, frame-ancestors | 없음 | <base> 요소, 폼 제출 대상, 이 페이지를 삽입할 수 있는 주체 |
nonce, 해시, 'strict-dynamic'
CSP Level 2 이상을 지원하는 브라우저에서는 같은 지시문에 nonce나 해시가 있으면 'unsafe-inline'이 무시되고, 'strict-dynamic'이 있으면 'self'와 호스트 소스도 무시되어 nonce가 있거나 그런 스크립트가 불러온 스크립트만 신뢰합니다. 분석기는 이를 반영합니다. nonce, 해시, 'strict-dynamic' 옆의 'unsafe-inline'은 아주 오래된 브라우저용 대체이므로 참고로만 표시하고, 그것이 없는 'unsafe-inline'은 스크립트에서는 오류, 스타일에서는 경고입니다.
또 nonce나 해시 없는 'strict-dynamic'(아무 효과가 없음), 128비트(Base64 22자)보다 짧은 nonce, self처럼 따옴표 없이 쓴 키워드(호스트 이름으로 읽힘), JSONP나 사용자 스크립트를 호스팅하는 것으로 알려진 허용 호스트도 보고합니다. 이런 호스트는 호스트 허용 목록을 우회하게 해 줍니다.
그 밖의 점검
오류에는 스크립트 제어 누락(script-src도 default-src도 없음), 스크립트 영역의 *나 data:, 중복 지시문이 있습니다. 경고에는 'unsafe-eval', 'unsafe-hashes', 스크립트에 대한 https: 같은 스킴 전체 소스, 평문 http: 소스, 다른 지시문의 *, 다른 소스와 섞인 'none', nonce 없는 'unsafe-inline'이 든 style-src, 더는 쓰지 않는 지시문(block-all-mixed-content, navigate-to, prefetch-src, plugin-types), 알 수 없는 지시문 이름, 없는 object-src 'none'·base-uri·frame-ancestors가 있습니다. 참고에는 없는 form-action이나 default-src, report-to 없는 report-uri, 엄격한 nonce 기반 정책, Trusted Types가 있습니다.
script-src-elem, fenced-frame-src, trusted-types, require-trusted-types-for 같은 새 이름은 알 수 없는 지시문으로 취급하지 않고 인식합니다.
실제 예시
default-src 'self'; script-src 'self' 'unsafe-inline' https://cdn.example.com; style-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; upgrade-insecure-requests지시문 7개, 소스 8개, 오류 1·경고 0·참고 1
오류 script-src: nonce나 해시 없이 'unsafe-inline' 허용
참고 form-action: 설정 없음
유효 정책: 이미지·글꼴·연결·프레임·워커는 default-src에 따라 제한됨, object-src와 frame-ancestors는 차단, form-action은 설정 없음주입된 인라인 스크립트가 실행되므로 정책의 보호 효과가 보기보다 훨씬 작습니다.
script-src *; script-src 'unsafe-eval'지시문 1개, 소스 1개, 오류 2·경고 3·참고 2
오류 script-src: 중복 지시문
오류 script-src: *(모든 출처) 허용
경고 object-src, base-uri, frame-ancestors: 누락
참고 form-action, default-src: 누락
유효 정책 script-src: 모든 출처, 나머지 모든 리소스: 제한 없음두 번째 script-src는 브라우저가 무시하므로 'unsafe-eval'은 보고되지 않습니다. 첫 번째 지시문만 적용됩니다.
Content-Security-Policy: default-src 'self'; img-src 'self'지시문 2개, 소스 2개, 오류 0·경고 3·참고 1
경고 object-src, base-uri, frame-ancestors: 누락
유효 정책: 스크립트는 default-src, 이미지는 img-src에 따름, base-uri와 frame-ancestors는 설정 없음헤더 이름은 분석 전에 제거되므로 지시문으로 잘못 읽히는 것이 없습니다.
default-src 'none'; script-src 'nonce-4AEemGb0xJptoIGFP3Nd1w' 'strict-dynamic' 'unsafe-inline' https:; style-src 'self'; img-src 'self' data: http://img.example.com; connect-src https://api.example.com; object-src 'none'; base-uri 'none'; frame-ancestors 'self'; form-action 'self'; report-uri /csp; require-trusted-types-for 'script'지시문 11개, 소스 16개, 오류 0·경고 1·참고 4
경고 img-src: 평문 HTTP 소스 http://img.example.com
참고 script-src: nonce나 'strict-dynamic' 옆의 'unsafe-inline'은 무시됨
참고 script-src: 엄격한 CSP
참고 report-uri: report-to 없음
참고 require-trusted-types-for: Trusted Types 필수'unsafe-inline'과 https: 대체는 감점하지 않습니다. http:// 이미지 소스가 실제 문제입니다.
default-src 'self'; script-src 'self' https://cdnjs.cloudflare.com; object-src 'none'; base-uri 'none'; frame-ancestors 'none'지시문 5개, 소스 6개, 오류 0·경고 1·참고 1
경고 script-src: https://cdnjs.cloudflare.com은 JSONP나 사용자 스크립트도 호스팅해 허용 목록을 우회할 수 있음
참고 form-action: 설정 없음호스트가 공격자가 영향을 줄 수 있는 스크립트를 제공하면 호스트 허용 목록은 우회됩니다. nonce와 'strict-dynamic'을 쓰면 이 문제를 피합니다.
default-src 'none'; object-src 'none'; base-uri 'none'; frame-ancestors 'none'; form-action 'self'지시문 5개, 소스 5개, 오류 0·경고 0·참고 0
유효 정책: 스크립트, 스타일, 이미지, 글꼴, 연결, 미디어, 프레임, 워커, 객체, 매니페스트 모두 차단, form-action은 제한됨발견 항목이 없다고 애플리케이션이 그 정책으로 동작한다는 뜻은 아닙니다. 소스를 추가하기 전에는 모든 스크립트와 스타일시트가 차단됩니다.
자주 하는 실수
깨끗한 보고서를 곧이곧대로 믿기
도구는 정해진 패턴 목록만 점검합니다. 정책이 통과해도 공격자가 조작할 수 있는 스크립트를 제공하는 호스팅 엔드포인트를 허용하거나, 보기보다 넓은 소스에 의존할 수 있습니다. 점검 목록과 함께 유효 정책 표도 읽으세요.
테스트 없이 unsafe-inline 제거하기
인라인 스크립트와 style 속성이 동작하지 않게 됩니다. nonce나 해시로 옮기고 먼저
Content-Security-Policy-Report-Only로 배포하세요.재사용되거나 너무 짧은 nonce
nonce는 예측할 수 없어야 하고 응답마다 새로 만들어야 합니다. 분석기는 길이만 확인할 수 있고 서버가 값을 재사용하는지는 알 수 없습니다.
meta 태그의 CSP는 더 약함
<meta http-equiv>로 전달한 정책은frame-ancestors,report-uri,sandbox를 무시합니다. 이들은 응답 헤더로 보내세요.여러 정책은 교집합으로 적용됨
서버가 CSP 헤더를 둘 이상 보내면 브라우저는 모두 적용합니다. 두 번째 헤더에 추가한 지시문은 첫 번째가 허용한 범위를 좁히기만 하며, 이 도구는 한 번에 정책 하나를 평가합니다.
자주 묻는 질문
도구가 내 사이트나 나열된 도메인에 접속하나요?
아니요. 붙여넣은 텍스트만 분석하며 나열된 어떤 출처에도 접속하지 않습니다.
nonce를 쓰면 unsafe-inline이 왜 참고로만 나오나요?
nonce를 지원하는 브라우저는 nonce, 해시, 'strict-dynamic'이 같은 지시문에 있으면 'unsafe-inline'을 무시합니다. 아주 오래된 브라우저를 위한 대체로 남아 있을 뿐이므로 오류가 아니라 참고로 보고합니다.
중복된 지시문은 어떻게 되나요?
브라우저는 첫 번째 것을 쓰고 나머지는 무시합니다. 뒤의 값은 효력이 없으므로 오류로 보고하며, 유효 정책 표는 첫 번째 값을 사용합니다.
유효 정책 표의 설정 없음은 무슨 뜻인가요?
지시문이 없고 적용되는 폴백도 없어서 브라우저가 그 리소스 종류에 아무 제한도 두지 않는다는 뜻입니다. base-uri, form-action, frame-ancestors가 보통 이 상태입니다.
CSP만으로 XSS를 막을 수 있나요?
'unsafe-inline'과 넓은 소스를 피하고 가능하면 Trusted Types까지 쓴다면 강력한 두 번째 방어선이 되지만, 출력 인코딩과 입력 검증은 여전히 필요합니다.
붙여넣은 정책이 업로드되나요?
브라우저 안에서 분석하며 이 도구가 서버로 전송하지 않습니다. 정책에 비밀이 들어 있는 경우는 드물지만 URL에 토큰이 붙은 보고 엔드포인트는 예외입니다.
더 깊이 읽기
마지막 업데이트: