"이스케이프하면 됩니다" 수준에서 멈추는지, 아니면 출력 컨텍스트별 인코딩과 CSP/sanitizer/쿠키 속성을 계층 방어로 엮어 설명하는지를 가른다. 프레임워크가 막아주는 범위와 그래도 남는 구멍을 구분하는지를 본다.
XSS는 신뢰된 도메인의 페이지에 끼어든 스크립트가 사용자 브라우저에서 실행되는 공격이고, 서버에 저장돼 다시 내려오는 Stored, URL/요청 파라미터가 그대로 박히는 Reflected, 클라이언트 JS가 위험한 싱크에 값을 넣는 DOM 기반으로 갈린다. 방어의 핵심은 "데이터를 어떤 컨텍스트에서 출력하는가"에 맞춰 인코딩하는 것이다. HTML 본문이면 이스케이프, 속성·URL·JS 컨텍스트면 각자 다른 규칙으로 막고, DOM 조작은 innerHTML 대신 textContent를 기본으로 둔다. CSP·HttpOnly는 1차 방어가 뚫렸을 때 피해를 좁히는 안전망이지 입력 검증을 대체하지 않는다.
dangerouslySetInnerHTML이나 v-html을 어쩔 수 없이 써야 했던 화면에서 sanitizer 정책을 어떻게 좁혔는지 풀어낼 수 있다
CSP를 Report-Only로 띄워 위반 로그를 보면서 인라인 스크립트·외부 도메인을 단계적으로 끊은 과정이 있다면 그대로 답변이 된다
사용자 입력을 받는 화면을 리뷰하면서 출력 컨텍스트별로 인코딩 위치를 옮긴 PR이 있으면 "왜 그 자리였는지"로 연결한다
외부 위젯/광고가 깨지는 걸 감수하고 CSP를 좁혔거나, 반대로 비즈니스 요구 때문에 정책을 푼 경험이 있다면 트레이드오프 사례로 쓸 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.