skip to content

How does the DelegatingFilterProxy get registered in a Spring Boot application, and how would you do it without Boot?

level: middleimportance: should knowfreq 45%

answer

  1. Boot: SecurityFilterAutoConfiguration + DelegatingFilterProxyRegistrationBean
  2. name must equal springSecurityFilterChain
  3. non-Boot: web.xml or AbstractSecurityWebApplicationInitializer
  4. order via spring.security.filter.order
  5. map to /*

basics

~10 s

In Boot, SecurityFilterAutoConfiguration registers a DelegatingFilterProxyRegistrationBean pointing at the springSecurityFilterChain bean. Without Boot you register it via web.xml or AbstractSecurityWebApplicationInitializer with the same bean name and a /* mapping.

solid answer

~40 s

In Spring Boot, once spring-security is on the classpath, SecurityFilterAutoConfiguration contributes a DelegatingFilterProxyRegistrationBean that registers the proxy with the servlet container and wires it to the springSecurityFilterChain bean (a FilterChainProxy contributed by WebSecurityConfiguration). It's ordered so security runs early. You write no XML. In a classic (non-Boot) servlet app you either declare a DelegatingFilterProxy filter in web.xml named springSecurityFilterChain mapped to /*, or extend AbstractSecurityWebApplicationInitializer, which programmatically registers the same proxy via the ServletContext during startup. In both cases the registration name must match the FilterChainProxy bean name so the lazy lookup resolves. The registration-bean approach in Boot is preferred because it keeps the proxy tied to a Spring bean and gets proper ordering.

go deeper

for a junior

Know Boot auto-registers it and you normally write nothing.

for a middle

Name the auto-config classes and the web.xml / initializer alternatives, plus the name-matching requirement.

for a senior

Discuss ordering (spring.security.filter.order), dispatcher types, and multi-context lookup.

for a principal

Reason about registration-order pitfalls, double registration, and dispatcher-type coverage for async/error.

## Spring Boot path When `spring-boot-starter-security` is present: 1. `WebSecurityConfiguration` (imported by `@EnableWebSecurity`, which Boot enables via `SecurityAutoConfiguration`) builds the `FilterChainProxy` and exposes it as the bean named `springSecurityFilterChain`. 2. `SecurityFilterAutoConfiguration` defines a `DelegatingFilterProxyRegistrationBean` that registers a `DelegatingFilterProxy` with the embedded servlet container, targeting the `springSecurityFilterChain` bean by name. 3. The registration is ordered via `SecurityProperties.DEFAULT_FILTER_ORDER` so security runs before most application filters. The default URL pattern is `/*`. `DelegatingFilterProxyRegistrationBean` is a specialized `RegistrationBean` that, unlike a plain `FilterRegistrationBean`, knows to build a `DelegatingFilterProxy` bound to a bean name and resolves it against the application context lazily. You get all this for free — no code. ## Overriding registration order in Boot You can customize via `spring.security.filter.order` and `spring.security.filter.dispatcher-types` properties, or by defining your own `SecurityFilterChain`/registration beans. Raising the order too high can let unsecured filters run before security. ## Classic servlet / web.xml path ```xml <filter> <filter-name>springSecurityFilterChain</filter-name> <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class> </filter> <filter-mapping> <filter-name>springSecurityFilterChain</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> ``` The `<filter-name>` doubles as the default `targetBeanName`, so it must equal the `FilterChainProxy` bean name `springSecurityFilterChain`. ## Programmatic (Servlet 3+) path Extend `org.springframework.security.web.context.AbstractSecurityWebApplicationInitializer`. Its `onStartup` registers the `DelegatingFilterProxy` named `springSecurityFilterChain` and maps it, so you don't touch `web.xml`. You can override `getDispatcherTypes()` and insertion order. ## Why the name must match By default `DelegatingFilterProxy` uses its **filter registration name** as the `targetBeanName`. If they differ, either set the `targetBeanName` init-param explicitly or you'll hit a `NoSuchBeanDefinitionException` for `springSecurityFilterChain` on the first request. ## Gotchas - Mapping the proxy to a narrower pattern than `/*` leaves paths unsecured. - In apps with both a root and a DispatcherServlet child context, the `FilterChainProxy` bean must be in the context the proxy searches (root by default). - Registering the proxy twice (e.g., manual + auto) causes the chain to run twice. - `DelegatingFilterProxy` only applies to `REQUEST` dispatcher type by default; ASYNC/ERROR dispatches may need explicit configuration (`spring.security.filter.dispatcher-types`). ## When to use each Boot apps: rely on auto-config, tweak via properties. Legacy WAR/servlet apps: `AbstractSecurityWebApplicationInitializer` (modern) or `web.xml` (older).

  • What property controls where the security filter sits in the overall filter order in Boot?
    spring.security.filter.order (default SecurityProperties.DEFAULT_FILTER_ORDER); it positions the DelegatingFilterProxy relative to other registered filters.

saying these in an interview costs you the question

  • Claiming you must manually register the proxy in Spring Boot
  • Thinking the filter-name/bean-name mismatch is harmless
  • Assuming it secures all dispatcher types by default

context

resolving links…