WEBBOOK CHAPTER

Spring Security 6, 인증에서 운영까지: 9장. CSRF를 끄기 전에 자격 증명 전달 방식을 본다

9장. CSRF를 끄기 전에 자격 증명 전달 방식을 본다

CSRF는 공격자 사이트가 사용자의 브라우저에 이미 들어 있는 cookie를 이용해 상태 변경 요청을 보내는 문제다. API가 JSON이라는 이유로 자동 면역이 되지 않는다. 브라우저가 자동 첨부하는 세션 cookie를 쓰면 상태 변경 요청에 CSRF token을 검증한다. Spring Security CSRF 문서를 기준으로 저장소와 프런트 계약을 정한다.


await fetch('/api/tenants/ACME/contracts/C-1042/actions/approve', {
  method: 'POST',
  headers: { 'X-CSRF-TOKEN': csrfToken }
});

csrf().disable()은 오류를 없애는 만능 해결책이 아니다. 오직 해당 체인이 브라우저가 자동 전송하지 않는 Bearer token만 받고, 로그인·logout·token endpoint 등 cookie 기반 상태 변경이 섞이지 않았음을 증명할 때 검토한다. 체인을 분리하면 근거가 명확해진다.

테스트는 성공 token만 보지 않는다.


mvc.perform(post("/api/tenants/ACME/contracts/C-1042/actions/approve")
    .with(user("bob").roles("MANAGER")))
  .andExpect(status().isForbidden());

logout도 상태 변경이다. GET logout을 편의상 허용하지 않는다. token 저장소, lazy token 발급, SPA cookie 이름과 header 이름이 프레임워크 버전에 따라 달라질 수 있으므로 프런트와 계약 테스트를 둔다.