CSP 헤더 빌더란?
콘텐츠 보안 정책(CSP)은 웹 페이지에 로드할 수 있는 콘텐츠 소스를 정의하여 XSS(교차 사이트 스크립팅), 클릭재킹 및 기타 코드 삽입 공격을 방지하는 데 도움이 되는 브라우저 보안 표준입니다. CSP 헤더 빌더는 지시문 구문을 기억하지 않고도 유효한 CSP 헤더 문자열을 구성할 수 있는 시각적 인터페이스를 제공합니다. 지시문을 켜거나 끄고 'self', 'unsafe-inline' 또는 특정 도메인과 같은 허용된 소스 값을 선택하면 도구가 실시간으로 올바른 헤더 문자열을 생성합니다. 또한 'unsafe-inline'을 'strict-dynamic'과 결합하거나 위험한 JavaScript 실행을 다시 활성화하는 'unsafe-eval'을 사용하는 등 충돌하거나 안전하지 않은 구성에 대해 경고합니다.
CSP 헤더 빌더를 사용하는 방법
- 1필요한 지시어를 켜서 활성화하세요. 기본 대체 정책으로 'default-src'으로 시작하세요.
- 2활성화된 각 지시어에 대해 허용하려는 소스 값(예: 'self', https:, data:)을 클릭합니다. 선택한 값은 파란색으로 강조 표시됩니다.
- 3입력 필드에 사용자 정의 도메인을 입력하고 Enter 키를 누르거나 추가(예: https://cdn.example.com)를 클릭하여 사용자 정의 도메인을 추가합니다.
- 4표시되는 노란색 경고를 검토하세요. 이는 충돌하거나 안전하지 않은 지시문 조합을 나타냅니다.
- 5복사 버튼을 사용하여 생성된 CSP 헤더 문자열 또는 HTML 메타 태그를 복사합니다.
- 6선택적으로 URL 테스트를 입력하여 현재 정책에 따라 허용 또는 차단되는지 확인하세요.
주요 활용 사례
웹 애플리케이션 보안 강화
인라인 스크립트를 차단하고, 리소스 원본을 제한하고, XSS 공격을 방지하려면 프로덕션 웹 사이트에 대해 엄격한 CSP 정책을 구축하세요. 제한적인 default-src 'none'으로 시작하고 애플리케이션에 필요한 소스만 선택적으로 허용하세요.
CSP로 점진적으로 마이그레이션
기존 애플리케이션에 CSP를 추가할 때 빌더를 사용하여 다양한 지시문 조합을 실험하고, 앱에 필요한 소스를 식별하고, 기능을 중단하지 않고 점차적으로 정책을 강화하세요.
CSP 위반 디버깅
브라우저 콘솔에 CSP 위반 오류가 표시되면 URL 테스트 기능을 사용하여 현재 정책에서 특정 리소스 URL이 허용되는지 확인하고 이에 따라 지시어를 조정하세요.
정적 사이트에 대한 메타 태그 생성
HTTP 헤더를 설정할 수 없는 플랫폼에서 호스팅되는 정적 사이트의 경우 생성된 HTML 메타 태그를 복사하여 CSP 정책을 HTML 문서의 헤드 섹션에 직접 삽입하세요.
자주 묻는 질문
HTTP 헤더로서의 CSP와 메타 태그의 차이점은 무엇입니까?
두 방법 모두 브라우저에 동일한 정책을 전달합니다. HTTP 헤더(Content-Security-Policy)는 서버가 설정하며 모든 지시어를 지원합니다. HTML 메타 태그(meta http-equiv Content-Security-Policy)는 페이지 안에 포함되며 대부분의 지시어에 사용할 수 있지만 frame-ancestors, report-uri, sandbox는 지원하지 않습니다. HTTP 헤더는 문서 HTML이 파싱되기 전에 적용되므로 일반적으로 더 선호됩니다.
'strict-dynamic'은 무엇을 하며 왜 'unsafe-inline'을 무시합니까?
'strict-dynamic'은 새로운 출처에서도 이미 신뢰할 수 있는 스크립트(nonce 또는 해시를 통해)에 의해 로드된 스크립트를 신뢰하도록 브라우저에 지시합니다. 'strict-dynamic'이 있으면 브라우저는 'unsafe-inline' 및 script-src에 대한 호스트 기반 허용 목록을 무시합니다. 이는 의도적으로 설계된 것입니다. 이는 명시적으로 nonce 스크립트만 실행되고 추가 스크립트를 동적으로 로드할 수 있는 nonce 기반 접근 방식을 가능하게 합니다.
항상 default-src를 설정해야 합니까?
예. default-src는 명시적으로 설정하지 않은 모든 지시문에 대한 기본값으로 동작합니다. 예를 들어 script-src는 정의했지만 style-src는 정의하지 않았다면 브라우저는 스타일에 default-src를 사용합니다. 보통 default-src를 'none' 또는 'self'로 설정해 안전한 기준선을 만든 뒤, 필요한 지시문만 개별적으로 완화하는 방식이 좋습니다.
'unsafe-eval'가 위험한 이유는 무엇입니까?
'unsafe-eval'을 사용하면 eval(), 새로운 Function(), 문자열이 포함된 setTimeout 및 기타 동적 코드 실행 API를 사용할 수 있습니다. 공격자가 애플리케이션에 문자열을 삽입할 수 있는 경우 임의의 JavaScript를 실행할 수 있기 때문에 이는 일반적인 XSS 공격 벡터입니다. 프레임워크나 라이브러리에서 절대적으로 요구하지 않는 한 'unsafe-eval'을 사용하지 마세요.
이 도구는 공식 사양과 비교하여 CSP 헤더의 유효성을 검사합니까?
이 도구는 구문적으로 올바른 CSP 헤더를 생성하고 일반적으로 충돌하거나 안전하지 않은 조합에 대해 경고합니다. 그러나 철저한 W3C 사양 검증을 수행하지는 않습니다. 프로덕션 배포의 경우 브라우저의 개발자 콘솔을 사용하여 스테이징 환경에서 CSP를 테스트하여 위반 사항을 찾아냅니다.