Precise Control of Filter Order in Spring Boot: A Case Study on Running MDC Filter After Spring Security

Introduction

In Spring Boot-based web applications, the execution order of Filters is critical to the request processing flow, especially when ensuring that specific Filters (e.g., MDC Filter for logging context) run after security-related Filters. However, many developers find that even with the @Order annotation or FilterRegistrationBean to set order, custom Filters may still execute before the Spring Security Filter. This article starts from the core mechanisms to analyze the root cause of this issue and provides effective solutions.

Problem Analysis

When Spring Security creates its Filter chain, it does not set an explicit order value for the generated Filter Bean by default. When Spring Boot automatically registers these Filters, they receive the default order value LOWEST_PRECEDENCE (i.e., Integer.MAX_VALUE). This means that if developers attempt to set the order of a custom Filter using @Order(Ordered.LOWEST_PRECEDENCE) or setOrder(Integer.MAX_VALUE), due to the same or smaller order value, the custom Filter may still be placed before the Spring Security Filter. For example, the following code tries to set the MDC Filter to the lowest priority, but it does not work as expected:

@Bean
@Order(Ordered.LOWEST_PRECEDENCE)
public UserInsertingMdcFilter userInsertingMdcFilter() {
    return new UserInsertingMdcFilter();
}

Similarly, using FilterRegistrationBean with setOrder(Integer.MAX_VALUE) cannot guarantee the order, as the Spring Security Filter may have the same order value.

Core Solution

To ensure that a custom Filter runs after the Spring Security Filter, the key is to explicitly register the Spring Security Filter and assign it a specific order value, then set a higher order value for the custom Filter. The specific steps are: First, register the Spring Security Filter via FilterRegistrationBean, injecting the default Security Filter using @Qualifier, and set its order to Integer.MAX_VALUE - 1. Then, register the custom Filter (e.g., MDC Filter) and set its order to Integer.MAX_VALUE. This way, the custom Filter has a higher order value and will execute after the Spring Security Filter. Below is the complete Java code example:

@Bean
public FilterRegistrationBean securityFilterChain(@Qualifier(AbstractSecurityWebApplicationInitializer.DEFAULT_FILTER_NAME) Filter securityFilter) {
    FilterRegistrationBean registration = new FilterRegistrationBean(securityFilter);
    registration.setOrder(Integer.MAX_VALUE - 1);
    registration.setName(AbstractSecurityWebApplicationInitializer.DEFAULT_FILTER_NAME);
    return registration;
}

@Bean
public FilterRegistrationBean userInsertingMdcFilterRegistrationBean() {
    FilterRegistrationBean registrationBean = new FilterRegistrationBean();
    UserInsertingMdcFilter userFilter = new UserInsertingMdcFilter();
    registrationBean.setFilter(userFilter);
    registrationBean.setOrder(Integer.MAX_VALUE);
    return registrationBean;
}

This method ensures the correct placement of the custom Filter by directly controlling the registration order of the Spring Security Filter. It is applicable to Spring Boot 1.x versions and addresses common pain points in Filter order management in earlier releases.

Supplementary Methods and Version Evolution

In addition to the core solution above, other methods are available for Filter order control. In Spring Boot 1.2 and later, the default order of the Spring Security Filter chain is set to 0, simplifying order management. Developers can adjust the order via configuration property security.filter-order=0, but this may not suit all custom scenarios. Furthermore, for cases requiring more flexible order control, the addFilterBefore or addFilterAfter methods of HttpSecurity can be used to insert Filters relatively within the Spring Security configuration. For example, in the configure method of WebSecurityConfigurerAdapter, one can specify that a custom Filter runs before or after a particular existing Filter:

@Override
protected void configure(HttpSecurity http) throws Exception {
    http.addFilterAfter(new UserInsertingMdcFilter(), SecurityContextPersistenceFilter.class);
}

This approach is suitable for Spring Boot 2 and Spring Security 5, allowing precise relative order control based on class names. Developers can verify the actual order of the Filter chain using debugging tools (e.g., setting a breakpoint in the doFilter method of FilterChainProxy) to ensure the configuration meets expectations.

Conclusion

Controlling Filter order in Spring Boot requires a deep understanding of the default registration mechanisms of Spring Security. By explicitly registering the Spring Security Filter and setting its order value, it is possible to reliably ensure that custom Filters execute afterward. With the evolution of Spring Boot versions, improvements in default order and relative order control methods via HttpSecurity offer more flexibility. Developers should choose the appropriate method based on specific needs and versions to achieve precise management of the request processing flow.