Start Learning
Javaneer
Back to stage
Module 4·Security

Spring Security & the Filter Chain

How Spring Security intercepts every request with a chain of filters that authenticate and authorize before your controller runs.

16 min readIntermediate
On this page

Right now anyone can call BookVault's API - including the POST and DELETE endpoints that change the catalog. That's fine for learning and catastrophic in production. Spring Security locks it down, and it does so with a mechanism you already understand from the Web module: filters.

Security is a chain of filters

Before a request ever reaches your DispatcherServlet and controllers, Spring Security runs it through a chain of servlet filters. Each filter has one job - read a token, establish who the user is, check permissions - and together they decide whether the request proceeds or is rejected.

Airport security, not a lock on every door

You don't put a separate lock on every gate, shop, and jet bridge in an airport. Instead, every traveler passes through one security checkpoint first: ID check, boarding-pass check, screening. Only cleared passengers reach the gates. Spring Security is that checkpoint - a chain every request passes through before it reaches any controller, so your controllers don't each reinvent security.

Authenticate, then authorize

Two of those filters matter most, and they run in order:

  1. Authentication - establish who is calling (validate a token or login), and store the result as an Authentication in the SecurityContext.
  2. Authorization - decide whether that caller is allowed to do this - based on their roles/authorities and the rule for the URL.

If authentication fails, the request is rejected with 401 Unauthorized. If the caller is authenticated but lacks permission, it's 403 Forbidden. Only a request that passes both reaches your controller.

A request through the security filter chainPick who's calling and watch the filters decide: authenticate, then authorize, before the controller ever runs.
POST /api/books

A request to create a book — a LIBRARIAN-only operation.

SecurityFilterChain

Before the controller, the request runs through Spring Security's ordered filter chain.

Authentication filter

Bearer token is valid → authenticated as a LIBRARIAN.

Authorization filter

Route needs ROLE_LIBRARIAN, and the user has it. Allowed.

201 Created

The request reaches BookController.add and the book is created.

Just add the starter

Adding Spring Security immediately secures everything - by default it requires authentication for every request and generates a login form and a random password:

<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
</dependency>

Secure by default

The instant you add the starter, every endpoint requires authentication - a deliberate "locked by default" stance. You then open up exactly what should be public (like the health check or a login endpoint) rather than trying to remember to lock things down. That default is a feature, not a nuisance.

401 or 403?

BookVault now uses Spring Security. For each case, say whether the response is 401 or 403, and why:

  1. A request with no credentials hits GET /api/books.
  2. An authenticated MEMBER sends DELETE /api/books/{isbn}, which requires the LIBRARIAN role.

How does Spring Security apply security to a web application?

Key takeaways

  • Spring Security runs every request through a chain of servlet filters before it reaches your controllers.
  • The two key steps are authentication (who are you?) then authorization (are you allowed?).
  • Failed authentication returns 401 Unauthorized; authenticated-but-forbidden returns 403 Forbidden.
  • Adding spring-boot-starter-security secures every endpoint by default - you then open up what should be public.
  • Because security lives in the filter chain, your controllers don't each have to implement it.
Was this lesson helpful?
Edit this page on GitHub