CSRF 실전: SPA + 쿠키 인증에서 왜 터지고 어떻게 막는지

CSRF 실전: SPA + 쿠키 인증에서 왜 터지고 어떻게 막는지

목표: 이 글을 읽고 나면 "어떤 선택이 우리 팀에 맞는지"를 기준으로 정할 수 있고, "바로 적용할 체크리스트"를 가져갈 수 있게 만드는 것입니다.

전제: 인기 있는 글은 "개념"보다 "결정"과 "실수 방지"에 시간을 씁니다. 그래서 이 글은 설명을 길게 늘리기보다, 기준/예시/검증 순서로 정리합니다.

이 글이 필요한 사람

• 인증/권한이 불안하고, 브라우저/쿠키/CSRF 같은 '규칙'에서 자주 터지는 팀
• 보안 설정을 켰더니 로그인/세션이 깨지는 경험을 한 팀
• 보안 사고를 '운영 프로세스'로 줄이고 싶은 팀

추천 기본값(실무에서 안전한 시작점)

• 기본값은 보수적으로(Secure/HttpOnly/SameSite 등), 예외는 문서화해서 승인 절차로
• 서버 로그에 민감정보를 남기지 않는다(마스킹/삭제가 기본)
• 보안은 기능이 아니라 운영 규칙(알람/감사/회수)까지 포함한다

핵심 포인트(요약)

• CSRF 실전: SPA + 쿠키 인증에서 왜 터지고 어떻게 막는지에서 팀이 합의해야 할 '기준'을 먼저 고정한다
• 실전 예시(헤더/설정/흐름)로 바로 적용 가능하게 만든다
• 운영에서 반복되는 실수를 체크리스트로 막는다

실전 내용(핵심만)

아래는 핵심만 남긴 본문입니다. 여기서 결정한 기준을 팀 문서로 옮기고, 체크리스트로 운영에 반영하는 것이 목표입니다.

팁: 읽다가 애매하면 '참고/출처'의 공식 문서로 규칙을 확인하는 습관을 추천합니다.

목표: 이 글을 읽고 나면 "어떤 선택이 우리 팀에 맞는지"를 기준으로 정할 수 있고, "바로 적용할 체크리스트"를 가져갈 수 있게 만드는 것입니다.

전제: 인기 있는 글은 "개념"보다 "결정"과 "실수 방지"에 시간을 씁니다. 그래서 이 글은 설명을 길게 늘리기보다, 기준/예시/검증 순서로 정리합니다.

이 글이 필요한 사람

• 인증/권한이 불안하고, 브라우저/쿠키/CSRF 같은 '규칙'에서 자주 터지는 팀
• 보안 설정을 켰더니 로그인/세션이 깨지는 경험을 한 팀
• 보안 사고를 '운영 프로세스'로 줄이고 싶은 팀

추천 기본값(실무에서 안전한 시작점)

• 기본값은 보수적으로(Secure/HttpOnly/SameSite 등), 예외는 문서화해서 승인 절차로
• 서버 로그에 민감정보를 남기지 않는다(마스킹/삭제가 기본)
• 보안은 기능이 아니라 운영 규칙(알람/감사/회수)까지 포함한다

핵심 포인트(요약)

• CSRF 실전: SPA + 쿠키 인증에서 왜 터지고 어떻게 막는지에서 팀이 합의해야 할 '기준'을 먼저 고정한다
• 실전 예시(헤더/설정/흐름)로 바로 적용 가능하게 만든다
• 운영에서 반복되는 실수를 체크리스트로 막는다

실전 내용(핵심만)

아래는 핵심만 남긴 본문입니다. 여기서 결정한 기준을 팀 문서로 옮기고, 체크리스트로 운영에 반영하는 것이 목표입니다.

팁: 읽다가 애매하면 '참고/출처'의 공식 문서로 규칙을 확인하는 습관을 추천합니다.

쿠키: XSRF-TOKEN=abc
헤더: X-XSRF-TOKEN: abc
서버는 두 값이 일치하는지 확인

자주 하는 실수(사고로 이어지는 패턴)

• 보안 설정을 '일단 켜고' 깨지는 곳을 땜질한다(원인 추적이 불가능해짐)
• 테스트 환경에서만 되는 설정을 프로덕션에 그대로 반영한다(도메인/HTTPS/프록시 차이)
• 민감정보(토큰/비밀번호)를 로그에 남겨 2차 사고를 만든다
• 권한을 역할만으로 단순화해서(혹은 반대로 너무 복잡하게) 운영이 망가진다
• CSRF 토큰을 헤더로 보내야 하는데 프리플라이트/헤더 정책에 막힌다

운영/검증 체크리스트(배포 전에 확인)

• 위협 모델을 한 줄로 적는다(무엇을 막아야 하나: CSRF/XSS/탈취/권한 상승)
• 설정 변경은 단계적으로(Report-Only/부분 롤아웃/관측) 적용
• 정책 예외는 사유/기간/소유자를 남긴다(만료 없는 예외 금지)
• 보안 이벤트(로그인 실패, 토큰 재사용, 권한 거부)를 지표/알람으로 운영
• 지원/복구 프로세스(2FA 분실, 계정 잠김)까지 합의
• 상태 변경 요청에 CSRF 토큰 검증이 들어가 있는가?

FAQ

Q. 보안 설정을 바꾸면 왜 로그인부터 깨지나요?
A. 대부분 쿠키 도메인/HTTPS/프록시 인식과 같은 '환경 차이'에서 시작합니다.

Q. CORS를 막으면 CSRF도 막히나요?
A. 아니요. CSRF는 브라우저의 쿠키 자동 전송과 관련이고, CORS는 서버 허용 정책입니다.

Q. 권한은 어디까지 엄격해야 하나요?
A. 사고 비용이 큰 리소스부터 엄격하게, 나머지는 단계적으로 강화하는 게 현실적입니다.

바로 실행용 스니펫

# 브라우저에서 쿠키/헤더 확인(예시)
curl -I https://example.com
# DevTools -> Application -> Cookies 도 함께 확인

참고/출처

버전/환경에 따라 동작이 달라질 수 있으니, 최종 기준은 공식 문서를 확인합니다.

• OWASP: CSRF Prevention Cheat Sheet
• Spring Security: CSRF

왜 이게 어려운가(운영 관점)

보안 설정은 '켜면 끝'이 아니라, '환경/브라우저/프록시'와 결합되어 실제로 어떻게 동작하는지가 중요합니다.

실무에서 가장 많은 사고는 보안이 약해서가 아니라, 보안 설정이 불명확해서(혹은 팀마다 다르게 이해해서) 발생합니다.

그래서 보안 글은 개념보다도 '기본값'과 '예외 승인', 그리고 '감사/복구 프로세스'까지 포함하는 게 효과적입니다.

적용 순서(추천)

• 1) 무엇을 막는지(위협 모델)를 한 줄로 적는다(CSRF/XSS/탈취/권한 상승 등)
• 2) 기본값을 보수적으로 정한다(Secure/HttpOnly/SameSite 등)
• 3) 예외는 만료일/사유/승인자를 남긴다(만료 없는 예외 금지)
• 4) E2E로 확인한다(도메인/HTTPS/프록시 포함, 로컬만 믿지 않기)
• 5) 보안 이벤트를 지표/알람으로 운영한다(로그인 실패/권한 거부/토큰 재사용 등)

검증/회귀 방지

• 브라우저 DevTools에서 쿠키/요청 헤더가 실제로 어떻게 붙는지 확인
• 프록시 뒤에서 HTTPS 인식이 올바른지 확인(X-Forwarded-Proto 등)
• 민감정보가 로그에 남지 않는지 샘플링 점검

팀 합의 템플릿(복붙용)

# 운영 규칙 템플릿(복붙용)
기본 쿠키 정책: HttpOnly; Secure; SameSite=Lax
예외: 크로스사이트 임베드 필요 시 SameSite=None; Secure(필수)
감사: 쿠키/토큰 정책 변경은 PR + 승인 필수
복구: 계정 잠김/2FA 분실 시 지원 프로세스 문서 링크

자주 하는 실수(사고로 이어지는 패턴)

• 보안 설정을 '일단 켜고' 깨지는 곳을 땜질한다(원인 추적이 불가능해짐)
• 테스트 환경에서만 되는 설정을 프로덕션에 그대로 반영한다(도메인/HTTPS/프록시 차이)
• 민감정보(토큰/비밀번호)를 로그에 남겨 2차 사고를 만든다
• 권한을 역할만으로 단순화해서(혹은 반대로 너무 복잡하게) 운영이 망가진다
• CSRF 토큰을 헤더로 보내야 하는데 프리플라이트/헤더 정책에 막힌다

운영/검증 체크리스트(배포 전에 확인)

• 위협 모델을 한 줄로 적는다(무엇을 막아야 하나: CSRF/XSS/탈취/권한 상승)
• 설정 변경은 단계적으로(Report-Only/부분 롤아웃/관측) 적용
• 정책 예외는 사유/기간/소유자를 남긴다(만료 없는 예외 금지)
• 보안 이벤트(로그인 실패, 토큰 재사용, 권한 거부)를 지표/알람으로 운영
• 지원/복구 프로세스(2FA 분실, 계정 잠김)까지 합의
• 상태 변경 요청에 CSRF 토큰 검증이 들어가 있는가?

FAQ

Q. 보안 설정을 바꾸면 왜 로그인부터 깨지나요?
A. 대부분 쿠키 도메인/HTTPS/프록시 인식과 같은 '환경 차이'에서 시작합니다.

Q. CORS를 막으면 CSRF도 막히나요?
A. 아니요. CSRF는 브라우저의 쿠키 자동 전송과 관련이고, CORS는 서버 허용 정책입니다.

Q. 권한은 어디까지 엄격해야 하나요?
A. 사고 비용이 큰 리소스부터 엄격하게, 나머지는 단계적으로 강화하는 게 현실적입니다.

바로 실행용 스니펫

# 브라우저에서 쿠키/헤더 확인(예시)
curl -I https://example.com
# DevTools -> Application -> Cookies 도 함께 확인

참고/출처

버전/환경에 따라 동작이 달라질 수 있으니, 최종 기준은 공식 문서를 확인합니다.

• OWASP: CSRF Prevention Cheat Sheet
• Spring Security: CSRF