Spring Security Filter Chain — How Requests Flow Through
Fast recall
Quick revision
Core answer
UsernamePasswordAuthenticationFilter, BearerTokenAuthenticationFilter) -> `AnonymousAuthenticationFilter` -> `ExceptionTranslationFilter` -> `AuthorizationFilter` (final access check, replaces FilterSecurityInterceptor in 6.x). The chain halts early if any check fails.Whether the candidate understands that Spring Security is filter-based and can reason about ordering and short-circuit behavior.
Thinking Spring Security hooks into the controller layer — it operates entirely at the servlet filter level, before DispatcherServlet.
Mention FilterChainProxy, SecurityFilterChain beans, and how multiple chains can match different URL patterns with different configurations.
Interview-ready guide
Interview answer
`FilterChainProxy`
- Spring registers one
DelegatingFilterProxywith the Servlet container - Delegates to
FilterChainProxy, which holds multipleSecurityFilterChainbeans - Each chain has a request matcher and an ordered list of security filters
- First matching chain wins; filters run in fixed order
Key filters in order
SecurityContextHolderFilter-> loadsSecurityContextfrom session or creates emptyHeaderWriterFilter-> security headersCorsFilter,CsrfFilter,LogoutFilterUsernamePasswordAuthenticationFilter-> form login POSTBearerTokenAuthenticationFilter-> JWT BearerBasicAuthenticationFilter-> HTTP BasicAnonymousAuthenticationFilter-> sets anonymous if no authExceptionTranslationFilter-> AuthenticationException -> 401, AccessDeniedException -> 403AuthorizationFilter-> last check; replacesFilterSecurityInterceptor
Multiple chains
- Define multiple
SecurityFilterChainbeans with@Order - First matching
requestMatcherwins - Pattern:
@Order(1)/api/**STATELESS JWT;@Order(2)/**session-based UI
Custom filter placement
addFilterBefore(custom, UsernamePasswordAuthenticationFilter.class)for auth filters- Extend
OncePerRequestFilterfor single-execution guarantee - Don't catch auth exceptions; let
ExceptionTranslationFilterhandle them
Common mistakes
- Permissive chain registered first catches everything
anyRequest()before specific rules blocks them- Custom filter at wrong position -> empty
SecurityContext - Mixing servlet and reactive in one app
Spring Security Filter Chain — How Requests Flow Through
Direct Answer
The Spring Security filter chain is a series of servlet filters that intercept every HTTP request before it reaches your controller. DelegatingFilterProxy delegates to FilterChainProxy, which holds one or more SecurityFilterChain beans. For each request, the first matching chain runs, and its filters execute in a fixed order: SecurityContextHolderFilter (loads context) -> headers/CORS/CSRF -> authentication filters (UsernamePasswordAuthenticationFilter, BearerTokenAuthenticationFilter) -> AnonymousAuthenticationFilter -> ExceptionTranslationFilter -> AuthorizationFilter (final access check, replaces FilterSecurityInterceptor in 6.x). The chain halts early if any check fails.
Common Mistakes & Pitfalls
Thinking Spring Security hooks into the controller layer — it operates entirely at the servlet filter level, before DispatcherServlet.
Check your understanding
Answer these without looking back at the article.
- How do you add a custom filter at a specific position in the chain?
- What happens when two SecurityFilterChain beans match the same URL?
- How does Spring Security 6 differ from Spring Security 5 in terms of filter chain configuration?
- Why did AuthorizationFilter replace FilterSecurityInterceptor in 6.x?
Related interview prep categories
2Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.