WEBBOOK CHAPTER

Spring Security 6, 인증에서 운영까지: 4장. 요청이 FilterChainProxy를 지나가는 순서를 읽는다

4장. 요청이 FilterChainProxy를 지나가는 순서를 읽는다

Servlet 애플리케이션에서 Spring Security는 표준 Servlet Filter로 통합된다. 컨테이너의 DelegatingFilterProxy가 Spring bean인 FilterChainProxy로 위임하고, 이 프록시가 요청에 맞는 SecurityFilterChain을 선택한다. Servlet 보안 구조를 읽을 때 클래스 이름보다 책임과 순서를 본다.


request
  -> security context 복원
  -> exploit protection / CORS
  -> authentication filter
  -> anonymous 처리
  -> authorization
  -> controller

여러 체인을 둘 때는 @OrdersecurityMatcher가 생명선이다. /api/** 체인과 웹 체인을 분리했다면 좁은 matcher가 먼저 와야 한다. 어느 체인에도 걸리지 않는 구멍, 넓은 체인이 먼저 잡아먹는 오류, 양쪽 설정이 다르다는 착각을 테스트한다.

디버그 로그는 로컬에서만 짧게 켠다.


logging:
  level:
    org.springframework.security: TRACE

TRACE에는 요청 경로와 인증 흐름이 많이 남는다. 운영에서 상시 사용하면 개인정보, 비용, 노이즈가 늘어난다. 조사 시간과 대상 pod를 제한하고 종료 시 원복한다. 필터를 임의 위치에 추가하기 전 공식 제공 DSL이나 addFilterBefore/After의 기준 필터를 문서화한다.