Blog

서론#

CSP(Content Security Policy)는
보안 관련 글을 보다 보면 빠지지 않고 등장한다.

스크립트 차단, XSS 방어, 클릭재킹 방지까지
마치 CSP 하나로 많은 문제가 해결되는 것처럼 보이기도 한다.

그래서 자연스럽게 이런 인식이 생긴다.

CSP를 설정하면 보안이 강화된다

이 말은 틀리지는 않지만,
중요한 전제가 빠져 있다.

CSP는 무엇을 해주고, 무엇을 해주지 않는지가
아주 분명한 정책이기 때문이다.

이 글은
CSP를 "만능 방패"로 오해하지 않기 위해,
그 역할과 한계를 정리한 기록이다.

CSP란 무엇인가#

CSP는
브라우저에게 이 페이지에서 무엇을 허용할지를
명시적으로 알려주는 보안 정책이다.

이 정책은
HTML이나 자바스크립트가 아니라
HTTP 응답 헤더로 전달된다.

Content-Security-Policy: script-src 'self';

중요한 점은
CSP가 코드를 수정하는 것이 아니라,
브라우저의 실행 판단을 제한한다는 것이다.

CSP가 막아주는 것#

CSP가 잘하는 일은 명확하다.

1. 의도하지 않은 스크립트 실행
   CSP는 어디에서 온 스크립트를 실행할 수 있는지 제한한다.

• 인라인 스크립트 차단
• 외부 스크립트 출처 제한
• eval 같은 위험한 실행 방식 차단

이 덕분에
XSS가 성공하더라도
스크립트가 실제로 실행되지 않게 만들 수 있다.

2. 클릭재킹의 일부
   CSP의 frame-ancestors 지시자는
   페이지가 어떤 곳에서 iframe으로 불릴 수 있는지 제한한다.

Content-Security-Policy: frame-ancestors 'none';

이 설정이 있으면
어떤 사이트도 이 페이지를 iframe 안에 넣을 수 없다.

즉,
내 페이지가 액자에 들어가지 않게 거부하는 방식으로
클릭재킹을 막는다.

3. 리소스 출처 통제
   스크립트뿐 아니라
   이미지, 폰트, 스타일시트 등도 통제 대상이다.

• 허용된 도메인만 리소스 로드
• 외부 리소스 오남용 방지
• 의도치 않은 데이터 유출 감소

이는
공격보다는 사고 방지에 가까운 역할이다.

CSP가 막아주지 않는 것#

여기서부터가 중요하다.

CSP는 강력하지만,
책임 범위가 명확히 제한된 도구다.

1. 로직 오류
   CSP는 잘못된 권한 체크나 서버 로직을 막아주지 않는다.

• 인증 없이 접근 가능한 API
• 잘못된 권한 분기
• 서버 단 검증 누락

이런 문제는
CSP와 아무 관련이 없다.

2. CSRF
   CSP는 요청이 "의도된 것인지"를 판단하지 않는다.

• 쿠키 자동 포함
• 사용자의 클릭
• 정상적인 요청 형식

이 구조는 CSP가 관여하지 않는다.

그래서 CSRF는
여전히 토큰, SameSite 쿠키 같은
별도의 방어가 필요하다.

3. 토큰 탈취 자체
   CSP는 토큰이 어디에 저장되어 있는지에는 관여하지 않는다.

• 로컬스토리지에 저장된 JWT
• 노출된 쿠키 값
• 개발자가 직접 출력한 민감 정보

CSP는
"실행"을 제한할 뿐,
이미 노출된 값을 되돌려주지 않는다.

CSP의 성격을 한 문장으로 정리하면#

CSP는
공격을 "없애는" 기술이 아니다.

공격이 성공하더라도
피해를 줄이기 위한 최종 안전망에 가깝다.

그래서 CSP는
단독으로 쓰일 때보다,
다른 보안 조치들과 함께 있을 때 의미가 있다.

그래서 CSP는 언제 의미가 커지는가#

CSP는 다음 전제가 있을 때 가장 효과적이다.

• XSS 가능성을 완전히 제거할 수 없다고 판단할 때
• 외부 스크립트 의존이 있는 서비스
• 사용자 입력이 많은 페이지
• 클릭재킹 방어가 필요한 화면

이때 CSP는
"완벽함"이 아니라
실패를 전제로 한 방어로 작동한다.

정리#

CSP는
무언가를 대신 책임져주지 않는다.

대신,
개발자가 허용한 범위 밖의 동작을
브라우저가 거부하도록 만든다.

그래서 CSP는
"있으면 안전한 것"이 아니라,
없으면 불안한 것에 가깝다.