굿바이 innerHTML, 반가워 setHTML: Firefox 148에서 한층 강화된 XSS 방어

innerHTML 은 정제와 삽입이 분리되어 있어 개발자가 sanitize 호출을 한 번만 빠뜨려도 뚫린다. setHTML() 은 정제를 삽입 API 내부로 끌어들여 '잊을 수 있는 단계'를 구조적으로 제거한다.

// 위험: sanitize 호출을 잊으면 바로 XSS
el.innerHTML = userInput;
el.innerHTML = DOMPurify.sanitize(userInput); // 매번 기억해야 함

// 안전: 정제가 API 에 내장
el.setHTML(userInput);

보안은 '누가 실수하지 않는가' 가 아니라 '실수해도 안전한가' 로 설계해야 한다.

세 레이어는 푸는 문제가 다르고, 함께 쓸 때 효과가 극대화된다.

setHTML 도입 후 Trusted Types 를 켜면 raw innerHTML 경로까지 전면 차단되므로, 복잡한 CSP 튜닝 없이도 XSS 재발을 막을 수 있다.

레거시 전체 재작성 없이 innerHTML = x 라인을 element.setHTML(x) 로 기계적으로 치환하는 것만으로 대부분의 XSS 벡터가 닫힌다. 브라우저 지원이 부족한 환경은 feature detection 으로 fallback 을 둔다.

if ('setHTML' in Element.prototype) {
  el.setHTML(html);
} else {
  el.innerHTML = DOMPurify.sanitize(html);
}

리치텍스트 에디터처럼 기본 설정이 깨는 경우는 SanitizerConfig 로 허용 목록을 정의한다.

[감점 답변] '다 안전하게 처리한다' 식으로 뭉뚱그리면 감점. [좋은 답변] 레이어를 구분한다.

• 이스케이프: 문자열 레벨 방어 (< 치환)
• CSP: 실행 정책 (리소스 허용 목록)
• DOMPurify: 라이브러리 호출 기반 정제 — 호출 누락 시 뚫림
• setHTML: API 내장 정제 — 잊어도 안전

조합: setHTML + Trusted Types 로 sink 를 강제하고, CSP 로 실행을 제한하는 defense in depth.

[감점 답변] '그냥 일괄 치환하면 된다' 는 현실성 감점. [좋은 답변] 우선순위를 정한다.

1. 가장 위험한 입력 경로 부터: 사용자 작성 HTML, 외부 피드, 댓글/리뷰
2. feature detection + DOMPurify fallback 으로 안전망
3. 리치텍스트/에디터는 SanitizerConfig 로 허용 목록 커스텀
4. Trusted Types 정책을 Report-Only 로 먼저 켜서 잔여 innerHTML 을 감지
5. 감지 끝나면 Enforce 모드로 승격

[감점 답변] 둘을 동의어처럼 말하면 감점. [좋은 답변] 레이어 차이를 명확히:

• Sanitizer = 콘텐츠 정제 (무엇이 들어갈 수 있는가)
• Trusted Types = 정제된 값만 sink 에 들어가도록 강제하는 정책 (어디에 들어갈 수 있는가)

Sanitizer 만 쓰면 여전히 누군가 raw innerHTML 을 쓸 여지가 남는다. Trusted Types 를 켜면 require-trusted-types-for 'script' 로 그 경로 자체를 CSP 수준에서 차단한다. 둘을 결합해야 '실수로 raw innerHTML' 까지 막힌다.