If you're working on a Spring Security (and especially an OAuth) implementation, definitely have a look at the Learn Spring Security course:
>> LEARN SPRING SECURITYMocking is an essential part of unit testing, and the Mockito library makes it easy to write clean and intuitive unit tests for your Java code.
Get started with mocking and improve your application tests using our Mockito guide:
Handling concurrency in an application can be a tricky process with many potential pitfalls. A solid grasp of the fundamentals will go a long way to help minimize these issues.
Get started with understanding multi-threaded applications with our Java Concurrency guide:
Spring 5 added support for reactive programming with the Spring WebFlux module, which has been improved upon ever since. Get started with the Reactor project basics and reactive programming in Spring Boot:
Since its introduction in Java 8, the Stream API has become a staple of Java development. The basic operations like iterating, filtering, mapping sequences of elements are deceptively simple to use.
But these can also be overused and fall into some common pitfalls.
To get a better understanding on how Streams work and how to combine them with other language features, check out our guide to Java Streams:
Get started with Spring and Spring Boot, through the Learn Spring course:
>> LEARN SPRINGExplore Spring Boot 3 and Spring 6 in-depth through building a full REST API with the framework:
Yes, Spring Security can be complex, from the more advanced functionality within the Core to the deep OAuth support in the framework.
I built the security material as two full courses - Core and OAuth, to get practical with these more complex scenarios. We explore when and how to use each feature and code through it on the backing project.
You can explore the course here:
Spring Data JPA is a great way to handle the complexity of JPA with the powerful simplicity of Spring Boot.
Get started with Spring Data JPA through the guided reference course:
Refactor Java code safely β and automatically β with OpenRewrite.
Refactoring big codebases by hand is slow, risky, and easy to put off. Thatβs where OpenRewrite comes in. The open-source framework for large-scale, automated code transformations helps teams modernize safely and consistently.
Each month, the creators and maintainers of OpenRewrite at Moderne run live, hands-on training sessions β one for newcomers and one for experienced users. Youβll see how recipes work, how to apply them across projects, and how to modernize code with confidence.
Join the next session, bring your questions, and learn how to automate the kind of work that usually eats your sprint time.
1. Overview
In this quick tutorial, weβll focus on writing a custom filter for the Spring Security filter chain.
Further reading:
Spring Security β @PreFilter and @PostFilter
Introduction to Java Config for Spring Security
Spring Boot Security Auto-Configuration
2. Creating the Filter
Spring Security provides a number of filters by default, and these are enough most of the time.
Of course, itβs sometimes necessary to implement new functionality by creating a new filter to use in the chain.
Weβll start by implementing the org.springframework.web.filter.GenericFilterBean.
The GenericFilterBean is a simple javax.servlet.Filter implementation that is Spring-aware.
We only need to implement a single method:
public class CustomFilter extends GenericFilterBean {
@Override
public void doFilter(
ServletRequest request,
ServletResponse response,
FilterChain chain) throws IOException, ServletException {
chain.doFilter(request, response);
}
}
3. Using the Filter in the Security Config
Weβre free to choose either XML configuration or Java configuration to wire the filter into the Spring Security configuration.
3.1. Java Configuration
We can register the filter programmatically by creating a SecurityFilterChain bean.
For example, it works with the addFilterAfter method on an HttpSecurity instance:
@Configuration
public class CustomWebSecurityConfigurerAdapter {
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
http.addFilterAfter(
new CustomFilter(), BasicAuthenticationFilter.class);
return http.build();
}
}
There are a couple of possible methods:
- addFilterBefore(filter, class) adds a filter before the position of the specified filter class.
- addFilterAfter(filter, class) adds a filter after the position of the specified filter class.
- addFilterAt(filter, class) adds a filter at the location of the specified filter class.
- addFilter(filter) adds a filter that must be an instance of or extend one of the filters provided by Spring Security.
3.2. XML Configuration
We can add the filter to the chain using the custom-filter tag and one of these names to specify the position of our filter.
For instance, it can be pointed out by the after attribute:
<http>
<custom-filter after="BASIC_AUTH_FILTER" ref="myFilter" />
</http>
<beans:bean id="myFilter" class="com.baeldung.security.filter.CustomFilter"/>
Here are all the attributes to specify exactly where to place our filter in the stack:
- after describes the filter immediately after which a custom filter will be placed in the chain.
- before defines the filter before which our filter should be placed in the chain.
- position allows replacing a standard filter in the explicit position by a custom filter.
4. Applying Spring Security Filter Only on Secured Endpoints
Modern applications often serve both public and secured endpoints. Applying a custom Spring Security filter globally can lead to unnecessary processing for public endpoints. To address this, we can target the filter specifically to secured endpoints by using Spring Securityβs SecurityFilterChain and RequestMatcher:
@Bean
public SecurityFilterChain securedFilterChain(HttpSecurity http) throws Exception {
http.authorizeHttpRequests(authorizationManagerRequestMatcherRegistry ->
authorizationManagerRequestMatcherRegistry.requestMatchers("/secured/**").authenticated())
.httpBasic(Customizer.withDefaults());
http.addFilterAfter(new CustomFilter(), BasicAuthenticationFilter.class);
return http.build();
}
This configuration ensures that security settings are only applied to endpoints matching /secured/**, as specified by requestMatchers(β/secured/**β).
The addFilterAfter(new CustomFilter(), BasicAuthenticationFilter.class) line ensures the custom filter is applied after the BasicAuthenticationFilter, meaning it will execute only after the basic authentication process.
This approach allows for targeted security processing on secured endpoints without affecting public ones. All requests to /secured/** require authentication, as enforced by .authorizeHttpRequests().
By using a custom SecurityFilterChain, we can isolate these security settings, keeping the applicationβs security modular and efficient. This setup prevents unnecessary overhead on public endpoints and ensures tailored authentication handling for secured paths, such as custom failure responses in the authentication entry point.
5. Conclusion
In this quick article, we created a custom filter and wired that into the Spring Security filter chain.
