CSP에 nonce를 붙이면 XSS를 완전히 막을 수 있나요? 서버 렌더링과 캐시에서 무엇을 주의하나요?
잠깐, 답변을 보기 전에
먼저 내 말로 설명해 볼까요?
답변과 점검 포인트 펼치기답변 접기
구두 답변
정의를 외우기보다, 원리와 조건을 연결해 설명해 보세요.
CSP nonce는 허용한 script에 예측하기 어려운 값을 붙여 실행을 제한하는 방어입니다. 출력 인코딩·입력 처리·안전한 DOM API를 대신하지 않으며 잘못된 정책이나 허용 스크립트의 취약점은 남습니다.
동작 원리와 전제
응답마다 새로운 nonce를 생성하고 헤더와 해당 script에 같은 값을 넣습니다. 공격자가 삽입한 태그에 nonce가 자동으로 복사되면 보호가 깨집니다. HTML 캐시에서 nonce를 재사용하거나 헤더와 본문이 다른 버전이 되는 경로를 확인합니다.
선택과 실패 처리
unsafe-inline·광범위 host 허용이 정책을 약하게 만들지 않는지 봅니다. report-only로 위반을 관찰한 뒤 정상 기능과 외부 스크립트 요구를 검토합니다. 보고 endpoint의 원문 정보·트래픽도 개인정보와 비용 관점에서 제한합니다.
구체적인 사례와 검증
서버 템플릿이 모든 script 태그에 nonce를 자동 삽입하는데 그 태그 중 일부가 사용자 입력에서 만들어졌다면 공격자 코드도 승인될 수 있습니다. nonce는 신뢰한 코드 위치에만 부여해야 합니다. 캐시된 HTML을 여러 사용자에게 재사용할 때는 nonce 생성·헤더·본문의 수명이 맞는지 확인합니다. report-only는 실행을 막지 않고 보고하는 모드이므로 보호가 이미 적용됐다고 보고하면 안 됩니다. 정책 위반이 0건이라는 것도 공격이 없거나 보고가 유실된 결과일 수 있어 실제 차단 테스트가 필요합니다. CSP는 입력 처리 결함을 고치는 동안 추가 방어를 제공하는 계층으로 유지합니다.
인라인·동적 로딩·템플릿 삽입·CDN 캐시·브라우저 지원을 시험합니다. CSP 통과를 안전한 HTML 생성의 증거로 보지 않습니다. 중요한 것은 신뢰한 코드의 범위를 좁히고 비신뢰 데이터가 실행 가능한 문법이 되지 않게 하는 것입니다.
득점 포인트
이해가 드러나는 지점을 확인해 보세요.
- 핵심 구분: CSP nonce는 허용한 script에 예측하기 어려운 값을 붙여 실행을 제한하는 방어입니다.
- 선택 조건: unsafe-inline·광범위 host 허용이 정책을 약하게 만들지 않는지 봅니다.
- 검증 기준: 인라인·동적 로딩·템플릿 삽입·CDN 캐시·브라우저 지원을 시험합니다.
감점 포인트
놓치기 쉬운 조건과 오해를 짚어 보세요.
- nonce를 붙이면 출력 인코딩과 안전한 DOM 처리가 필요 없다고 한다.
더 파고들 거리
하나 더 질문하며 이해의 범위를 넓혀 보세요.
- 브라우저의 요청 위조와 스크립트 실행은 서로 어떤 방어 경계를 요구하나요?
- 서버 표현과 클라이언트 초기 상태가 다르면 실제 상호작용을 어떤 단계에서 검증하나요?
- 같은 URL의 사용자·언어·압축 표현이 캐시에 섞이지 않게 어떤 키를 유지하나요?
득점·감점 포인트는 학습용 자기 점검 기준이며, 특정 회사의 실제 채점표가 아닙니다.
원리부터 공부하고 싶다면
답변을 보충하는 개념·예제·슈도코드를 읽어 보세요.