DOM XSS vs Reflected XSS — 종류별로 어떻게 막나

1. 먼저 XSS를 구분해야 하는 이유

1) 같은 XSS라도 발생 지점이 다릅니다

웹 보안에서 XSS는 익숙한 키워드지만, 실제로는 발생 방식에 따라 대응이 달라집니다. 특히 DOM XSS와 Reflected XSS는 비슷해 보이지만, 공격이 만들어지는 위치와 차단 방법이 다르기 때문에 구분해서 이해하는 것이 중요합니다.

2) 왜 검색하는 사람이 많은가

개발 중 에러는 없는데도 브라우저에서 이상한 동작이 생기거나, 특정 입력값을 넣었을 때 스크립트가 실행되는 문제를 겪는 경우가 있습니다. 이때 많은 사람이 XSS종류를 찾아보게 되며, “내가 겪는 문제가 DOM XSS인지, Reflected XSS인지”를 먼저 확인하려고 합니다.

3) 이 글에서 다룰 내용

이 글에서는 DOM XSS, Reflected XSS, 그리고 실무에서 자주 놓치는 innerHTML위험까지 함께 정리합니다. 어떤 상황에서 각 취약점이 생기기 쉬운지, 어떻게 막아야 하는지, 그리고 기본 점검 도구를 어떤 식으로 활용할 수 있는지까지 설명해보겠습니다.

2. DOM XSS란 무엇인가

1) 브라우저 안에서 발생하는 XSS

DOM XSS는 서버 응답이 아니라, 브라우저에서 실행되는 자바스크립트가 위험한 방식으로 데이터를 처리하면서 생기는 취약점입니다. 즉, 서버가 직접 악성 스크립트를 내려주지 않아도, 클라이언트 측 코드가 URL 파라미터나 해시값 같은 입력을 읽어 화면에 넣는 과정에서 문제가 생길 수 있습니다.

2) 실무에서 자주 보이는 형태

예를 들어 location.search, location.hash, document.referrer 같은 값을 읽어서 그대로 DOM에 넣는 코드가 있을 수 있습니다. 이때 필터링이나 이스케이프 없이 innerHTML에 삽입하면, 공격자가 조작한 값이 태그나 스크립트처럼 해석될 가능성이 생깁니다. 이런 이유로 innerHTML위험은 DOM XSS를 이야기할 때 빠지지 않는 주제입니다.

3) 왜 발견이 늦어질까

DOM XSS는 서버 로그에 흔적이 남지 않거나, 정적 점검만으로는 놓치기 쉬워서 뒤늦게 발견되는 경우가 많습니다. 사용자는 단순히 링크를 클릭했을 뿐인데 페이지 동작이 바뀌거나 경고창이 뜨는 식으로 나타나기 때문에, 프론트엔드 코드 리뷰가 중요합니다.

3. Reflected XSS란 무엇인가

1) 요청값이 응답에 그대로 반영되는 구조

Reflected XSS는 사용자가 보낸 입력값이 서버에서 처리된 뒤, 응답 HTML에 그대로 반영되면서 발생하는 취약점입니다. 검색어, 에러 메시지, 파라미터 값이 화면에 보여지는 기능에서 자주 나타나며, 입력값 검증이 부족하면 공격 페이로드가 그대로 실행될 수 있습니다.

2) URL 하나로 유입되는 경우가 많습니다

Reflected XSS는 보통 악성 링크를 클릭했을 때 실행되는 형태로 많이 알려져 있습니다. 사용자가 의심 없이 URL을 열면, 서버가 그 값이 포함된 페이지를 반환하고, 브라우저가 이를 해석하면서 스크립트가 동작하는 식입니다. 그래서 외부 유입이 많은 서비스나 검색 결과 페이지에서 특히 주의가 필요합니다.

3) DOM XSS와의 차이

DOM XSS가 브라우저 내부 코드의 문제라면, Reflected XSS는 서버가 요청값을 응답에 반영하는 구조에서 비롯됩니다. 둘 다 사용자의 입력이 최종적으로 스크립트 실행으로 이어진다는 점은 같지만, 막는 방식은 다릅니다. 그래서 XSS종류를 구분할 때는 “데이터가 어디서 어떻게 흘러가는가”를 먼저 보는 것이 좋습니다.

4. XSS종류를 이해할 때 확인해야 할 지점

1) 입력값의 출처

가장 먼저 봐야 할 것은 데이터가 어디서 들어오는지입니다. URL 파라미터, 해시값, 폼 입력, 쿠키, 로컬스토리지처럼 여러 경로가 있을 수 있는데, 이 값이 화면에 반영되는 시점에 보안 처리 여부를 확인해야 합니다.

2) 출력 방식

같은 값을 출력하더라도 textContent처럼 텍스트로 처리하는지, 아니면 innerHTML처럼 HTML로 해석되는지에 따라 위험도가 달라집니다. 특히 innerHTML위험은 코드상으로 편해 보여도, 사용자 입력을 다룰 때는 조심해야 하는 대표적인 예입니다.

3) 서버와 브라우저의 역할 분리

어떤 문제는 서버에서 해결해야 하고, 어떤 문제는 프론트엔드에서 막아야 합니다. 예를 들어 서버는 응답값을 적절히 이스케이프해야 하고, 브라우저 쪽에서는 위험한 DOM 조작을 줄여야 합니다. DOM XSS, Reflected XSS를 함께 이해하면 이 역할 분담이 더 명확해집니다.

5. DOM XSS를 막는 방법

1) 위험한 DOM API를 피하기

가장 기본적인 대응은 innerHTML처럼 HTML 해석이 일어나는 API 사용을 줄이는 것입니다. 가능하면 textContent, createTextNode, 안전한 템플릿 렌더링 방식처럼 텍스트 중심의 출력 방법을 사용하는 편이 좋습니다.

2) 입력값을 신뢰하지 않기

URL에서 가져온 값이거나 사용자 입력이라면, “그럴 리 없다”는 전제로 코드를 짜지 않는 것이 중요합니다. 특히 해시값은 간단해 보여도 공격자가 조작하기 쉬우므로, 그대로 화면에 넣는 구조는 피하는 것이 좋습니다.

3) 보안 헤더와 정책도 함께 보기

DOM XSS는 코드 수정만으로 끝나지 않는 경우도 있습니다. CSP(Content Security Policy)처럼 스크립트 실행 범위를 줄여주는 설정을 함께 적용하면 피해를 낮추는 데 도움이 됩니다. 다만 이는 보조 수단에 가깝고, 근본적으로는 위험한 DOM 조작을 줄이는 것이 우선입니다.

6. Reflected XSS를 막는 방법

1) 출력 시 이스케이프가 핵심

Reflected XSS 대응에서 가장 중요한 것은 서버가 응답을 만들 때 입력값을 안전하게 이스케이프하는 것입니다. HTML, 속성값, 스크립트 컨텍스트마다 필요한 처리 방식이 다르므로, 단순 치환만으로 끝내기보다 출력 위치에 맞는 방식을 써야 합니다.

2) 검증보다 출력 보호가 더 중요할 때가 있습니다

입력값 검증도 필요하지만, “특정 문자만 막으면 된다”는 식의 방식은 우회되기 쉽습니다. 실제로는 허용할 값의 범위를 정하는 것과 함께, 최종 출력 단계에서 안전하게 처리하는 것이 더 중요합니다.

3) 에러 메시지와 검색 결과 페이지 점검

Reflected XSS는 검색 결과, 필터 조건, 오류 안내문처럼 사용자의 입력을 다시 보여주는 화면에서 자주 발견됩니다. 이런 페이지는 기능상 입력값을 표시해야 하므로, 개발할 때부터 “어떤 값이 화면에 다시 나오는지”를 기준으로 확인하는 습관이 필요합니다.

7. 기본 점검을 어떻게 활용하면 좋을까

1) 출시 전 최소한의 보안 점검에 적합합니다

복잡한 보안 체계를 모두 갖추기 전이라도, 핵심적인 문제부터 확인하는 것이 중요합니다. 이때 URL만 입력해 기본 보안 상태를 빠르게 살펴보는 도구는 초기 점검에 도움이 될 수 있습니다. 예를 들어 HTTPS, 인증서, 보안 헤더 같은 기본 설정뿐 아니라 브라우저에서 드러나는 위험 요소를 함께 보는 방식이 가능합니다.

2) 실제 프로젝트에서 놓치기 쉬운 항목을 찾는 데 유용합니다

개발이 진행되다 보면 쿠키 설정, CORS, API 접근 권한, 정보 노출 여부 같은 항목이 뒤로 밀리는 경우가 많습니다. 또한 .env, 소스코드, API 키 노출처럼 직접적인 사고로 이어질 수 있는 부분도 기본 점검 단계에서 확인해두면 좋습니다. DOM XSS나 Reflected XSS처럼 실행 맥락이 중요한 문제도, 이런 기본 상태를 함께 살펴볼 때 더 빨리 발견되는 경우가 있습니다.

3) 정밀 진단의 대체재는 아닙니다

중요한 점은 이런 점검이 모든 취약점을 완전히 찾아주는 것은 아니라는 점입니다. 특히 복잡한 로직 취약점이나 인증 흐름 문제는 별도의 분석이 필요할 수 있습니다. 다만 반복적으로 발생하는 기본 취약점, 예를 들면 innerHTML위험이나 잘못된 보안 헤더 설정은 빠르게 확인해두는 것만으로도 도움이 큽니다.

8. 정리: 어떤 상황에서 대비해야 할까

1) 개발 초기부터 XSS 종류를 구분하는 습관이 필요합니다

DOM XSS, Reflected XSS는 이름만 비슷한 것이 아니라 대응 지점이 다릅니다. 프론트엔드에서 값을 읽어 화면에 넣는지, 서버가 요청값을 그대로 응답에 반영하는지에 따라 점검 포인트가 달라지므로, XSS종류를 나눠 이해하는 것이 실무에서 중요합니다.

2) innerHTML은 특히 주의해서 봐야 합니다

사용자 입력이 들어가는 위치에 innerHTML을 쓰는 순간, 의도하지 않은 해석이 일어날 가능성이 커집니다. 물론 모든 innerHTML이 곧바로 취약점은 아니지만, 안전한 대안이 있는지 먼저 검토하는 편이 좋습니다.

3) 기본 점검과 코드 검토를 함께 가져가면 좋습니다

서비스가 빠르게 성장하거나 여러 페이지가 반복적으로 추가되는 경우, 기본 보안 상태를 주기적으로 확인하는 것이 도움이 됩니다. 이런 상황에서는 URL 기반으로 기본 상태를 살펴보는 점검 도구를 함께 활용하고, 직접 전화나 수동 문의처럼 즉시 답을 받는 방식과 비교해보면 차이가 있습니다. 전화는 특정 이슈를 빠르게 설명하기 좋지만, 화면과 설정을 넓게 훑어보는 데는 한계가 있습니다. 반면 Vibe Guardian처럼 URL을 입력해 기본 보안 상태를 빠르게 점검하는 방식은, DOM XSS와 Reflected XSS를 포함한 기본 위험 요소를 초기 단계에서 확인하는 데 유용한 편입니다.