CSRF 토큰 (CSRF Token) — Brain Science

핵심 인사이트 (3줄 요약)

CSRF 토큰은 서버가 각 세션이나 요청마다 생성하는 고유한 난수(Nonce)로, 공격자가 이를 예측하거나 획득하는 것을 차단한다.
사용자의 브라우저가 자동으로 포함하는 쿠키와 달리, 토큰은 클라이언트 측에서 명시적으로 요청에 포함해야 하므로 인증된 요청임을 보장한다.
가장 널리 사용되는 전통적인 CSRF 방어 기법이며, 동기적 토큰 패턴(Synchronizer Token Pattern)이 대표적이다.

Ⅰ. 개요 (Context & Background)

정의: 웹 애플리케이션이 변조 요청을 식별하기 위해 서버에서 발행하여 클라이언트로 전달하고, 후속 요청 시 다시 서버로 전송받아 검증하는 임의의 문자열이다.
방어 원리: 브라우저는 모든 요청에 쿠키를 자동으로 포함시키지만, CSRF 토큰은 공격자가 사용자의 페이지 내용을 읽을 수 없는 한(SOP 제약) 탈취가 불가능하다는 점을 이용한다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

동기적 토큰 패턴 (Synchronizer Token Pattern): 서버 세션에 토큰을 저장하고, 클라이언트의 폼(Form) 필드나 헤더에 포함된 토큰과 대조한다.

[ CSRF Token Flow ]
+-------------------+ (1) GET /transfer    +-------------------+
|      Client       | --------------------> |      Server       |
|    (Browser)      | <-------------------- |  (Session Store)  |
+-------------------+ (2) Response + Token  +-------------------+
          |            (Hidden Field)                 |
          |                                           |
          | (3) POST /transfer                        |
          |     + Token (Value)                       |
          v                                           v
+-------------------------------------------------------------+
| Server Side Validation:                                     |
| if (Request.Token == Session.Token) { Accept() }            |
| else { Reject(403 Forbidden) }                              |
+-------------------------------------------------------------+

토큰의 요건:
- 예측 불가능성: 암호학적으로 안전한 난수 생성기(CSPRNG)를 사용해야 한다.
- 고유성: 세션당 최소 하나, 또는 요청당 하나씩 고유하게 생성되어야 한다.
- 보안성: URL 파라미터가 아닌, Hidden Form 필드나 Custom HTTP Header를 통해 전송해야 한다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

비교 항목	CSRF 토큰 (Synchronizer)	Double Submit Cookie	SameSite Cookie
저장 위치	서버 세션 (Server-side)	클라이언트 쿠키 (Client-side)	브라우저 설정 (Browser-side)
장점	보안성이 가장 높음	무상태(Stateless) 구현 가능	설정이 매우 간편함
단점	서버 메모리 부담 가능성	세션 고정 공격에 취약할 수 있음	구형 브라우저 미지원
검증 방식	세션 값과 직접 대조	쿠키 값과 파라미터 값 대조	브라우저가 전송 여부 결정
주요 적용	중요 트랜잭션 (금융)	SPA, 분산 아키텍처	기본 방어 레이어

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

기술사적 판단: CSRF 토큰은 단순한 '문자열 대조' 이상의 의미를 갖는다. 이는 클라이언트와 서버 간의 '신뢰된 통로'를 확인하는 절차이며, XSS 취약점이 존재할 경우 토큰이 탈취될 수 있으므로 XSS 방어가 선행되어야 한다.
실무 구현 전략:
- Custom Header 활용: AJAX 요청 시 X-CSRF-TOKEN과 같은 커스텀 헤더를 사용하면, 브라우저의 CORS 정책에 의해 제3자 사이트의 요청이 자동으로 차단되는 부가 효과를 얻을 수 있다.
- Stateless 환경 (JWT): 세션을 사용하지 않는 경우, 토큰을 JWT의 Claim에 포함시키거나 별도의 암호화된 토큰을 사용하여 검증한다.

Ⅴ. 기대효과 및 결론 (Future & Standard)

기대효과: 정상적인 서비스 흐름을 거치지 않은 모든 외부/불법 요청을 서버 입구에서 원천 차단하여 비정상적인 데이터 변조를 막는다.
결론: 프레임워크(Spring Security, Django 등)에서 기본적으로 제공하는 기능을 적극 활용하고, 비표준 요청 모델에서도 일관된 토큰 검증 정책을 유지하는 것이 보안의 정석이다.

📌 관련 개념 맵 (Knowledge Graph)

상위 개념: 웹 취약점 대응, 세션 관리 (Session Management)
직접 위협: CSRF (Cross-Site Request Forgery)
관련 기술: SOP (Same-Origin Policy), CORS, Anti-Forgery Token

👶 어린이를 위한 3줄 비유 설명

"우리 집 문을 열 때마다 매번 바뀌는 비밀번호를 서버에서 알려주는 것"과 같아요.
나쁜 사람이 내 이름으로 편지를 보내려고 해도, "오늘의 비밀번호"를 모르면 편지함이 열리지 않아요.
오직 나랑 서버 아저씨만 아는 암호라고 생각하면 된답니다!