📚[Spring] 스프링시큐리티 내부구조 -1

텁텁·2025년 6월 24일

시큐리티 내부 구조 - 1

사용자의 요청을 감시하려면?

WAS(톰캣)에서 Filter Chain 을 통해 요청을 처리한다.
그 중 하나가 DelegatingFilterProxy (스프링에서 등록한 필터)
해당 프록시 필터가 실제로 스프링 컨테이너 내부의 FilterChainProxy 로 요청을 위임
FilterChainProxy 는 내부에 등록된 SecurityFilterChain 목록을 기반으로 시큐리티의 인증/인가와 같은 로직을 수행한다.
시큐리티 필터를 다 통과하고 난 뒤 다시 WAS 의 나머지 필터를 수행하거나 컨트롤러로 요청이 전달된다.

DelegatingFilterProxy -> FilterChainProxy -> 다시 WAS 필터 흐름으로 복귀

직접 작성하거나 커스텀할 경우는 거의 없기 때문에 이런구조로 진행된다 정도만 알기로 하자.

SecurityFilterChain

스프링 시큐리티 의존성을 추가하면 우리가 따로 설정하지 않을 시 기본 보안 설정이 적용된 DefaultSecurityFilterChain 이 자동으로 등록된다.
커스터마이징이 필요하다면 SecurityFilterChain 을 반환하는 @Bean 메소드를 정의해 직접 등록할 수 있다.

@Configuration
@EnableWebSecurity
public class SecurityConfig {
	@Bean
	public SecurityFilterChain filterChain1(HttpSecurity httpSecurity) throws Exception {
        return httpSecurity
			.authorizeHttpRequests(auth -> auth
                .requestMatchers("/admin/**").permitAll()
                .anyRequest().authenticated())
            .build();
	}
}

SecurityFilterChain 은 N개를 등록할 수도 있으며 FilterChainProxy 는 각 필터체인의 RequestMatcher 를 순서대로 검사하여
가장 먼저 매칭되는 하나의 체인만 선택해 실행한다.
따라서 등록순서가 매우 중요하며 필요시 @Order 어노테이션을 통해 명시적으로 순서를 제어할 수 있다.

@Order를 명시하지 않으면 등록된 순서대로 검사되므로 (/**)와 같은 너무 넓은 matcher 가 위에 오면 다른 체인이 작동하지 않을 수 있다.

설정 초반에 .securityMatcher() 를 사용해 이 체인이 어떤 요청에 매칭될지 지정할 수 도 있다.

@Bean
public SecurityFilterChain adminFilterChain(HttpSecurity http) throws Exception {
    return http
        .securityMatcher("/admin/**")  // RequestMatcher 역할: 이 체인은 /admin/** 요청에만 적용한다는 뜻
        .authorizeHttpRequests(auth -> auth.anyRequest().authenticated())
        .build();
}

시큐리티 제공 필터 간단 설명

DisableEncodeUrlFilter

URL로 간주되지 않는 부분을 포함하지 않도록 설정

WebAsyncManagerIntegrationFilter

Spring MVC 의 @Async, Callable, DeferredResult 같은 비동기 처리와 시큐리티 컨텍스트를 연결

SecurityContextHolderFilter

인증된 사용자 정보를 SecurityContextHolder에 저장하고 쓰레드 간 보안 컨텍스트 유지

HeaderWriterFilter

보안 관련 HTTP 헤더를 응답에 추가(예: X-Content-Type-Options, X-Frame-Options, Cache-Control)

스프링 시큐리티의 헤더 관련 설정은 대부분 여기서 처리

CorsFilter

교차 출처 요청(CORS)에 대한 처리

CsrfFilter

CSRF(Cross Site Request Forgery) 공격을 방지하기 위한 필터

서버가 제공한 토큰과 클라이언트 요청의 토큰을 비교

LogoutFilter

/logout 요청을 처리하는 시작점

로그아웃 시 세션 무효화, SecurityContext 초기화, 인증 쿠키 삭제 등

기본은 GET: /logout 이며 커스터마이징 가능하다.

UsernamePasswordAuthenticationFilter

/login 요청을 처리하는 필터

사용자가 제출한 username과 password를 추출해 AuthenticationManager에 인증을 요청하여 성공시 SecurityContext에 인증정보 저장

DefaultLoginPageGeneratingFilter

별도의 로그인 페이지를 만들지 않았을 때 기본 로그인 페이지 GET: /login을 생성하여 응답

비활성화하거나 커스터마이징 가능

DefaultLogoutPageGeneratingFilter

기본 로그아웃 페이지 생성 GET: /logout

커스터마이징 가능

BasicAuthenticationFilter

Authorization: Basic 이하토큰 헤더가 포함된 요청을 처리

HTTP Basic 인증 기반으로 헤더에서 username/password 추출 후 인증 처리

RequestCacheAwareFilter

인증 후 원래 접근하려던 URL이 있을 경우 해당 URL로 redirect

인증 도중 요청이 인터셉트되면 성공 후 요청으로 리다이렉트하도록 도와줌

SecurityContextHolderAwareRequestFilter

서블릿 API에서 제공하는 보안 관련 메서드들을 시큐리티 컨텍스트와 연동

AnonymousAuthenticationFilter

인증되지 않은 요청에 대해 자동으로 익명 사용자로 설정

SecurityContext 가 비어있을 경우 익명 인증 객체(AnonymousAuthenticationToken)를 삽입

따라서 시큐리티는 항상 인증 객체를 가지고 동작

ExceptionTranslationFilter

인증 실패나 인가 실패 예외에 대한 적절한 처리 수행

인증 실패 -> 로그인 페이지로 redirect

인가 실패 -> 403 에러 반환

시큐리티 필터 중 예외 핸들링의 핵심 필터

AuthorizationFilter

최종 인가 로직 수행 : 경로, 권한, 역할 등 정책에 따라 접근 가능 여부 판단

컨트롤러 실행 전 인가 로직에 따라 접근을 허용하거나 차단

SecurityFilterChain 필터 활성화/비활성화

@Bean
public SecurityFilterChain customFilterChain(HttpSecurity http) throws Exception {
    http
		// 비활성화 예시
		.cors(cors -> cors.disable()) // CorsFilter 비활성화
		.csrf(csrf -> csrf.disable()) // CsrfFilter 비활성화
		.httpBasic(httpBasic -> httpBasic.disable()) // BasicAuthenticationFilter 비활성화

		// 활성화 예시
		.formLogin(withDefaults()) // UsernamePasswordAuthenticationFilter 활성화 (기본 로그인 폼)
		.logout(withDefaults()); // LogoutFilter 활성화 (기본 로그아웃 처리)
    
	return http.build();
}