XSS를 방어하기 위해 프론트엔드와 서버에서 어떤 처리가 필요하나요?

XSS는 공격자가 삽입한 스크립트가 다른 사용자의 브라우저에서 실행되는 취약점입니다. 방어를 위해 서버에서는 입력 검증과 저장 데이터 정제를 수행하고, 프론트엔드에서는 출력 인코딩, 위험한 HTML 삽입 제한, CSP 적용, 쿠키 보안 속성 설정을 함께 고려해야 합니다.

핵심 개념

핵심 기준은 신뢰할 수 없는 입력의 안전한 출력입니다. 이 개념은 단순히 용어를 외우는 것보다, 어떤 문제를 줄이기 위해 등장했는지와 실제 코드나 운영 환경에서 어떤 trade-off를 만드는지 함께 이해하는 것이 중요합니다.

웹 애플리케이션은 사용자 입력을 다시 화면에 보여주는 일이 많습니다. 이때 입력을 그대로 HTML로 해석하게 만들면 스크립트 실행으로 이어질 수 있으므로, 데이터가 들어오는 지점과 나가는 지점 모두에서 방어해야 합니다.

동작 흐름

1. 사용자 입력이나 외부 데이터를 받습니다.
2. 서버에서 허용 가능한 형식인지 검증하고 필요한 경우 정제합니다.
3. 화면 출력 시 HTML 문맥에 맞게 인코딩합니다.
4. CSP와 쿠키 속성으로 피해 범위를 줄입니다.

실제 예시

// 기본 텍스트 렌더링은 React가 이스케이프합니다.
<p>{userComment}</p>

// dangerouslySetInnerHTML은 검증된 HTML에만 제한적으로 사용합니다.

React의 기본 텍스트 렌더링은 안전한 편이지만, 직접 HTML을 삽입하는 순간 별도의 정제 전략이 필요합니다.

실무에서 주의할 점

• 클라이언트 검증만 믿으면 우회될 수 있으므로 서버 검증이 필요합니다.
• HTML sanitizer를 사용할 때도 허용 태그와 속성 정책을 명확히 해야 합니다.
• CSP는 보조 방어선이지 입력/출력 처리를 대체하지 않습니다.

함께 연결해서 보면 좋은 키워드

보안, XSS, CSP, 입력검증

면접에서 짚으면 좋은 포인트

• XSS 방어는 입력 검증보다 출력 인코딩이 핵심이라는 점을 분명히 하는 것이 좋습니다.
• CSP, HttpOnly, SameSite는 피해 범위를 줄이는 보조 방어선으로 설명하면 균형 잡힌 답변이 됩니다.

정리

한 줄로 정리하면, XSS 방어는 신뢰할 수 없는 입력을 검증하고, 출력 시 안전하게 인코딩하며, CSP 같은 보조 방어를 함께 적용하는 과정입니다. 실무에서는 개념을 적용하는 조건과 적용하지 않았을 때 생기는 문제까지 함께 이해하는 것이 중요합니다.