CSRF

한 줄 정의

CSRF는 사용자가 로그인한 브라우저가 인증 쿠키를 자동 전송한다는 특성을 악용해, 사용자의 의도와 다른 상태 변경 요청을 보내게 만드는 공격이다.

실무에서 왜 문제 되는가

브라우저는 같은 사이트의 쿠키를 자동으로 붙이므로 사용자가 공격 페이지를 열기만 해도 요청이 발생할 수 있다.
조회 API보다 주문, 결제, 비밀번호 변경, 이메일 변경 같은 상태 변경 API에서 위험하다.
CORS를 막았다고 CSRF가 자동으로 해결되는 것은 아니다.
쿠키 기반 인증을 쓰면서 SameSite, CSRF token, Origin 검증을 고려하지 않으면 우회될 수 있다.

동작 원리

사용자가 서비스에 로그인해 인증 쿠키를 가진 상태가 된다.
공격자는 사용자의 브라우저가 특정 상태 변경 요청을 보내게 만든다.
브라우저는 조건에 따라 인증 쿠키를 요청에 포함한다.
서버가 요청의 출처나 CSRF token을 확인하지 않으면 정상 사용자 요청으로 처리한다.
서버는 상태 변경 요청에서 token, Origin, SameSite 정책을 함께 검증해야 한다.

실무 판단 기준

상황	대응	이유
쿠키 기반 세션 인증	CSRF token 또는 SameSite 설정	브라우저 자동 쿠키 전송을 제어한다
상태 변경 요청	POST/PUT/PATCH/DELETE 보호	사용자 의도가 중요한 요청이다
Authorization header 기반 API	CSRF 위험 낮음	브라우저가 임의 header를 자동으로 붙이지 않는다
외부 도메인 form 요청 차단	Origin/Referer 검증	token 외 추가 방어선이 된다
SameSite=None	Secure 필수	cross-site 쿠키 전송 위험을 명시적으로 다룬다

자주 나는 실수

CORS 설정만으로 CSRF가 해결된다고 생각한다.
GET 요청으로 상태를 변경한다.
SameSite 기본값에만 의존하고 브라우저/환경 차이를 확인하지 않는다.
CSRF token을 쿠키에만 저장하고 요청 값과 비교하지 않는다.
JSON API라서 CSRF가 불가능하다고 단정한다.

확인 방법

테스트: 인증 쿠키가 있는 상태에서 외부 origin의 상태 변경 요청이 거부되는지 확인한다.
테스트: CSRF token 누락 또는 불일치 요청이 실패하는지 확인한다.
코드 리뷰: GET 요청이 상태를 변경하지 않는지 확인한다.
보안 점검: 쿠키의 SameSite, Secure, HttpOnly 설정을 확인한다.

장점과 한계

대응	장점	한계
CSRF token	사용자 의도 확인에 효과적이다	토큰 발급과 검증 흐름이 필요하다
SameSite cookie	브라우저 수준에서 cross-site 전송을 줄인다	모든 환경과 요구사항을 단독으로 해결하지 않는다
Origin 검증	구현이 비교적 단순하다	일부 요청에서 header가 없거나 프록시 영향이 있을 수 있다

짧은 예제

POST /orders/123/cancel HTTP/1.1
Cookie: SESSION=...
X-CSRF-TOKEN: token-from-server

쿠키 기반 인증에서 상태 변경 요청은 인증 쿠키 외에 사용자의 의도를 확인할 수 있는 값을 함께 검증한다.

핵심 요약

CSRF는 브라우저가 인증 쿠키를 자동으로 전송하는 특성을 악용한다.

위험은 주로 상태 변경 API에서 발생한다.

CORS는 브라우저의 응답 접근 제어이고 CSRF 방어와 목적이 다르다.

쿠키 기반 인증은 CSRF token, SameSite, Origin 검증을 함께 고려한다.

GET 요청은 상태를 변경하지 않아야 한다.

Authorization header 기반 API는 상대적으로 CSRF 위험이 낮지만 토큰 저장 위치에 따른 다른 위험을 봐야 한다.

꼬리 질문

CORS와 CSRF는 어떤 점이 다른가?
쿠키 기반 인증에서 CSRF를 어떻게 막을 것인가?
GET 요청으로 상태를 바꾸면 왜 위험한가?

관련 문서