8.8 KiB
title, source_type, url, archive_url, status, confidence, related_branches, related_projects, tags, created, last_reviewed
| title | source_type | url | archive_url | status | confidence | related_branches | related_projects | tags | created | last_reviewed | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| OWASP Content Security Policy Cheat Sheet — CSP header, unsafe-inline/unsafe-eval, XSS defense-in-depth | official-doc | https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html | raw | high |
|
|
|
2026-07-19 | 2026-07-19 |
OWASP Content Security Policy Cheat Sheet
Layer:
raw/official-docs/— OWASP Foundation 발행 Content Security Policy cheat sheet. ca-skeleton-frontendFE-OC-019(browser security boundary) 의 CSP-compatibility 결정 근거 — "왜 bundle 이 inline script / eval 을 피해야 strict CSP 를 적용할 수 있는가" 의 1차 reference. CSP 자체는 W3C spec 이며 header 값 은 hosting/backend header owner 소유(본 branch 범위 밖), 본 자료는 frontend 가 만족해야 할 compatibility 원칙만 근거한다.
Parent / 활용 branch (필수)
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| raw/branch-notes/feature-frontend-browser-security-boundary-contract | frontend bundle 이 unsafe-inline/unsafe-eval 없는 strict CSP 아래에서 동작하도록 inline script·eval·dynamic code 를 금지하는 결정의 근거. CSP header 값 자체는 hosting/backend header owner 소유(delegated). |
컨텍스트 / 왜 저장했는지
feature-frontend-browser-security-boundary-contract 의 hub 근거(§13.2)는 "CSP 는 hosting/backend header owner 와 frontend compatibility test 의 공동 책임" 이라고만 말하고, 왜 frontend bundle 이 inline script/eval 을 피해야 하는지의 메커니즘(strict CSP 가 unsafe-inline/unsafe-eval 없이는 inline script 와 eval 을 차단)은 hub 나 6개 build-tool 공식 문서에 없다. 이 cheat sheet 가 그 메커니즘을 직접 명시하므로 CSP-compatibility 결정의 외부 근거로 보관한다.
출처 / Source
- 원본 URL: https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
- 아카이브 URL: (미수집)
- 저자 / 조직: OWASP Foundation (Cheat Sheet Series — 커뮤니티 합의 + foundation 발행)
- 발행일: rolling docs
- 마지막 확인일: 2026-07-19 (WebFetch verbatim 확인)
- 관련 표준: W3C Content Security Policy Level 3 (본 cheatsheet 는 운영 권고, normative spec 아님)
핵심 인용 / Key quotes (verbatim, captured 2026-07-19)
[§How to use CSP] "Send a Content-Security-Policy HTTP response header from your web server."
[§Directives] "'unsafe-inline' Allows the usage of inline scripts or styles."
[§Directives] "'unsafe-eval' Allows the usage of eval in scripts."
[§CSP against XSS] "By preventing the page from executing inline scripts, attacks like injecting
<script>document.body.innerHTML='defaced'</script>will not work."
[§CSP against XSS] "By preventing the page from loading scripts from arbitrary servers, attacks like injecting
<script src=\"https://evil.com/hacked.js\"></script>will not work."
[§Introduction] "A strong CSP provides an effective second layer of protection against various types of vulnerabilities, especially XSS."
Claims Extracted / 추출된 주장
이 자료가 직접 말하는 것만 claim 으로 분리한다. 내 프로젝트 적용 결론은 아래에 포함하지 않는다.
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| OWASP-CSP-C1 | CSP 는 web server 가 보내는 Content-Security-Policy HTTP response header 로 전달된다 |
[§How to use CSP] "Send a Content-Security-Policy HTTP response header from your web server." | official-reference (OWASP cheatsheet — W3C spec 별도) |
CSP header 의 소유·전달 위치(server/hosting 응답 헤더) 판정 | frontend bundle 이 header 값을 결정한다는 뜻은 아님 — header 는 server/hosting 소유 |
| OWASP-CSP-C2 | 'unsafe-inline' 은 inline script/style 사용을 허용한다; 즉 이 keyword 가 없으면 inline script 는 실행되지 않아 <script>...innerHTML='defaced'</script> 주입이 무력화된다 |
[§Directives] "'unsafe-inline' Allows the usage of inline scripts or styles." + [§CSP against XSS] "By preventing the page from executing inline scripts, attacks like injecting <script>document.body.innerHTML='defaced'</script> will not work." |
official-reference |
strict CSP 아래에서 bundle 이 inline script 를 피해야 하는 이유 | nonce/hash 로 특정 inline script 를 allowlist 하는 방식의 세부는 본 인용 범위 밖 |
| OWASP-CSP-C3 | 'unsafe-eval' 은 script 안에서 eval 사용을 허용한다; 즉 이 keyword 가 없으면 eval/dynamic code 실행이 차단된다 |
[§Directives] "'unsafe-eval' Allows the usage of eval in scripts." | official-reference |
strict CSP 아래에서 bundle·의존성이 eval/new Function 을 피해야 하는 이유 |
어떤 라이브러리가 eval 을 쓰는지, 그 탐지 방법은 본 인용 범위 밖 |
| OWASP-CSP-C4 | strong CSP 는 XSS 등에 대한 effective second layer(defense-in-depth) 이며, arbitrary server 로부터의 script 로드를 막아 <script src="https://evil.com/hacked.js"> 주입을 무력화한다 |
[§Introduction] "A strong CSP provides an effective second layer of protection against various types of vulnerabilities, especially XSS." + [§CSP against XSS] "By preventing the page from loading scripts from arbitrary servers, attacks like injecting <script src=\"https://evil.com/hacked.js\"></script> will not work." |
official-reference |
CSP 를 primary XSS 방어가 아닌 second layer 로 자리매김하는 판정(=frontend 의 injection 금지 default 가 여전히 primary) | CSP 만으로 XSS 가 완전히 방지된다는 뜻은 아님 — second layer |
Usage Boundaries / 적용 경계
- 이 자료가 직접 증명하는 것 (2026-07-19 WebFetch verbatim 확인):
OWASP-CSP-C1: CSP 는 HTTP response header 로 전달(서버/hosting 소유).OWASP-CSP-C2:'unsafe-inline'이 inline script/style 을 허용하며, 없으면 inline script 실행 차단.OWASP-CSP-C3:'unsafe-eval'이eval을 허용하며, 없으면eval/dynamic code 차단.OWASP-CSP-C4: CSP 는 XSS 에 대한 second layer(defense-in-depth)이고 arbitrary-source script 로드를 차단.
- 이 자료가 증명하지 않는 것:
- 특정 프로젝트가 사용해야 할 정확한 directive 집합(
default-src 'self'등) — 배포 환경·hosting 정책 의존, header owner 결정. - CSP 만으로 XSS 가 완전히 방지된다는 명제 — second layer 임을 명시.
- nonce/hash 기반 inline script allowlist 의 구체 문법 — 본 인용 범위 밖.
- HSTS/frame/referrer 등 다른 security header 정책 — 별도 문서(OWASP HSTS cheat sheet 등).
- 특정 프로젝트가 사용해야 할 정확한 directive 집합(
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- ca-skeleton-frontend bundle 과 그 의존성이 실제로 inline script/eval 을 요구하지 않는지 build 산출물 검사(compatibility fixture).
- 실제 CSP directive 값은 hosting/backend header owner branch(release·cache·header 정책) 가 정의 — 본 branch 는 값이 아닌 compatibility 만 검증.
메모 / Notes
본 섹션은 자료 직접 인용 아님. ca-skeleton-frontend 해석.
- header 소유 경계:
OWASP-CSP-C1이 "CSP는 server가 보내는 응답 header"라고 명시하므로, ca-skeleton-frontend에서 CSP directive 값은 hosting/backend header owner 소유다.feature-frontend-browser-security-boundary-contract는 값이 아니라 bundle이 그 정책과 호환되는가(inline script/eval 미의존)만 책임진다. - second layer 위치:
OWASP-CSP-C4가 CSP를 "second layer"로 규정하므로, injection 기본 금지(lint)와 output encoding이 primary 방어로 남고 CSP는 보완이다. CSP가 있으니 injection lint를 완화해도 된다고 해석하면 안 된다. - nonce/hash: 불가피한 inline이 필요할 때 nonce/hash로 특정 script를 allowlist하는 방식은 본 cheatsheet 범위 밖이며 header owner 결정이다. skeleton default는 inline 자체를 만들지 않는 것.
- OWASP cheatsheet는 권고이며 강제 표준이 아님. W3C CSP spec이 normative.
Related / 관련
- 같은 주제 다른 official-doc:
- raw/official-docs/owasp-hsts-cheat-sheet — 다른 security response header(HSTS)
- raw/official-docs/owasp-html5-storage-xss-spa — browser storage 의 XSS 노출
- 인용하는 branch:
- 인용하는 project:
- 인용하는 wiki: (미작성)