CSRF 공격이란? 원리부터 방어 방법까지 정리

CSRF 공격이란? 원리부터 방어 방법까지 정리

웹 서비스를 개발하다 보면 반드시 한 번쯤 마주치게 되는 보안 이슈가 바로 CSRF(Cross-Site Request Forgery)입니다. 개념 자체는 단순하지만, 실제 서비스에서는 생각보다 쉽게 뚫릴 수 있는 취약점이기도 합니다.

📌 한 줄 요약
CSRF는 “사용자가 의도하지 않은 요청을, 이미 로그인된 상태를 이용해 대신 실행시키는 공격”입니다.

 

1️⃣ CSRF 공격의 핵심 원리

CSRF 공격은 브라우저의 쿠키 자동 전송 특성을 악용합니다. 사용자가 로그인한 상태라면, 다른 사이트에서 발생한 요청이라도 쿠키는 자동으로 함께 전송됩니다.

공격 흐름

1. 사용자가 A 사이트에 로그인 (쿠키 발급)
2. 로그인 상태로 공격자가 만든 B 사이트 접속
3. B 사이트에서 A 사이트로 요청 전송
4. 브라우저가 쿠키를 자동 포함 → 요청 성공

📎 실제 예시

<img src="https://example.com/user/delete?id=123" />

사용자는 단순히 이미지를 본 것뿐이지만, 서버 입장에서는 “로그인된 사용자가 삭제 요청을 보낸 것”으로 인식하게 됩니다.

 

2️⃣ CSRF가 위험한 이유

• 비밀번호 변경
• 회원 탈퇴
• 결제 요청
• 권한 변경

⚠️ 중요한 포인트
CSRF는 서버 인증이 정상적으로 통과된 상태에서 발생하기 때문에 로그만 보면 정상 요청처럼 보입니다.

 

3️⃣ CSRF 방어 방법

✅ 1. CSRF Token (가장 일반적인 방법)

서버에서 예측 불가능한 토큰을 발급하고, 클라이언트가 요청 시 함께 전달하도록 합니다.

<input type="hidden" name="csrf_token" value="랜덤토큰값" />

• 토큰이 없거나
• 토큰이 일치하지 않으면

→ 요청을 거부

✅ 2. SameSite 쿠키 설정

Set-Cookie: sessionId=xxx; SameSite=Strict

다른 사이트에서 발생한 요청에는 쿠키를 보내지 않도록 제한합니다.

• Strict: 완전 차단 (보안 최고)
• Lax: 일부 GET 요청 허용

✅ 3. Referer / Origin 검증

요청 헤더의 Origin 또는 Referer를 검사하여 신뢰된 도메인에서 온 요청만 허용합니다.

💡 실무 팁
이 방식은 보조 수단으로 사용하고, CSRF Token과 함께 적용하는 것이 안전합니다.

 

4️⃣ JWT 기반 서비스는 CSRF가 안전할까?

흔히 “JWT는 CSRF에 안전하다”라고 말하지만, 조건부로만 맞는 말입니다.

• Authorization Header에 직접 토큰 전달 → 상대적으로 안전
• JWT를 쿠키에 저장 → CSRF 위험 존재

❗ 오해 주의
JWT = CSRF 완전 방어는 아닙니다. 저장 방식이 핵심입니다.

마무리 정리

• CSRF는 브라우저의 쿠키 자동 전송을 악용한 공격
• 사용자 인증을 우회하는 것이 아니라, 사용자를 속인다
• CSRF Token + SameSite 설정이 가장 현실적인 방어

개인적으로도 실무에서 “POST니까 안전하겠지”라고 생각했다가 CSRF 이슈로 다시 설계했던 경험이 있습니다. 보안은 항상 의심하는 습관이 중요한 것 같습니다.