Chapter 5: A web app’s security begins with filters

Introduction

This chapter introduction explains how Spring Security’s HTTP filters form a chain and why applications may need to customize it.

• HTTP filter chain responsibilities: Explain how an HTTP request moves through Spring Security’s filter chain and what each filter does.
  Why it matters: This is the basic model for understanding where security behavior runs during a web request.
• Reasons to customize filters: Justify why an application might add or replace filters rather than rely on the default configuration, using examples from the section.
  Why it matters: Customizing the chain lets security behavior fit requirements that the defaults do not cover.

Key terms: HTTP filters, filter chain, chain of responsibilities, custom filters, default configurations, HTTP Basic authentication

5.1 Implementing filters in the Spring Security architecture

This section explains how Spring Security filters process requests in an ordered chain, how configuration affects that chain, and where custom filters can be placed.

• Filter implementation and forwarding: Describe how to implement an HTTP filter and what the arguments to doFilter() are used for.
  Why it matters: This is the basic contract for writing a filter that participates in request processing.
• Configuration-dependent chain membership: Explain why the filters present in an application's chain depend on its security configuration, using HTTP Basic as an example.
  Why it matters: It prevents you from assuming that every Spring Security filter runs in every application.
• Filter positions and ordering: Explain how filters are positioned in the chain and what happens when multiple filters share a position.
  Why it matters: Placement determines when custom logic runs, while a shared position cannot guarantee which filter runs first.

Key terms: Filter, jakarta.servlet, doFilter(), ServletRequest, ServletResponse, FilterChain, filter chain, httpBasic(), BasicAuthenticationFilter, CsrfFilter

5.2 Adding a filter before an existing one in the chain

Shows how to validate a required request header with a custom filter placed before authentication in Spring Security’s filter chain.

• Request validation filter behavior: Trace how RequestValidationFilter handles requests with and without the mandatory Request-Id header, and explain why it runs before authentication.
  Why it matters: Rejecting an invalid request early can avoid unnecessary authentication work.
• Filter placement before authentication: Describe how the example adds RequestValidationFilter before the authentication filter using the security configuration.
  Why it matters: Implementing a filter alone does not place its check at the required point in the security chain.

Key terms: RequestValidationFilter, Request-Id, doFilter(), HTTP 400 Bad Request, SecurityFilterChain, HttpSecurity, addFilterBefore(), BasicAuthenticationFilter

5.3 Adding a filter after an existing one in the chain

This section shows how to place a custom filter after an authentication filter to run post-authentication logic, using request logging as the example.

• Post-authentication filter placement: Explain when to place a custom filter after an existing filter and how this section adds one after the authentication filter.
  Why it matters: Filter placement determines when your custom logic runs relative to authentication.
• Successful request logging example: Describe what the example logs and why it treats requests that pass the authentication filter as successful authentication events.
  Why it matters: The logging example makes the effect of placing a filter after authentication observable.

Key terms: filter chain, addFilterAfter(), HttpSecurity, authentication filter, successful authentication events, request ID, HTTP header, console

5.4 Adding a filter at the location of another in the chain

The section shows how to place a custom authentication filter at a known position in the Spring Security filter chain, using static-key authentication as an example.

• Filter placement and ordering: Explain how addFilterAt() places a custom filter at the position of a known filter without replacing it, and why multiple filters at that position are best avoided.
  Why it matters: A custom filter’s position alone does not prevent an unwanted filter from running alongside it.
• Static-key filter behavior: Trace how the example filter authenticates a request using the Authorization header and what it does when the key matches or does not match.
  Why it matters: This example makes the request-handling responsibility of a custom authentication filter concrete.
• Alternative authentication approaches: Distinguish the static-key example from the signed-request and one-time-password scenarios described as alternatives to HTTP Basic.
  Why it matters: The examples show why an application might supply a different authentication filter instead of using HTTP Basic.
• Static-key security tradeoff: Explain why the section treats static-key authentication as a simple but weak compromise and where it says production secrets should be stored.
  Why it matters: The demonstration’s convenience should not be mistaken for a production security recommendation.
• Unneeded default user service: Explain why this example does not need a UserDetailsService despite Spring Boot configuring one automatically, and how the section says to disable that autoconfiguration.
  Why it matters: It separates this key-checking example from user-based authentication and explains an otherwise unnecessary default component.

Key terms: addFilterAt(), filter chain, BasicAuthenticationFilter, StaticKeyAuthenticationFilter, static key, Authorization header, 401 Unauthorized, HTTP Basic, symmetric keys, signature

5.5 Filter implementations provided by Spring Security

This section explains when to use Spring Security’s filter base classes, especially OncePerRequestFilter, instead of implementing Filter directly.

• Once Per Request Filtering: Explain why a filter might extend OncePerRequestFilter and how its filtering logic is supplied.
  Why it matters: It lets you avoid repeated work, such as logging the same request multiple times.
• Choosing a Filter Base: Distinguish when to use the provided filter base classes from when to implement Filter directly.
  Why it matters: Choosing a base class for a feature you need keeps filter implementations simple.
• Request And Dispatch Applicability: Describe the request types and application controls of OncePerRequestFilter.
  Why it matters: These controls let you decide which requests and dispatches should reach your filter logic.

Key terms: OncePerRequestFilter, doFilterInternal(), filter chain, Filter, GenericFilterBean, web.xml, HttpServletRequest, HttpServletResponse, shouldNotFilter(HttpServletRequest), shouldNotFilterAsyncDispatch()

5.6 Summary