Spring Security & die Filterkette
Wie Spring Security jede Anfrage mit einer Filterkette abfängt, die authentifiziert und autorisiert, bevor dein Controller läuft.
Deutsche Übersetzung in Arbeit
Diese Lektion ist noch nicht ins Deutsche übersetzt und wird daher auf Englisch angezeigt. Der Rest der Seite ist vollständig lokalisiert.
Auf dieser Seite
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.
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:
- Authentication - establish who is calling (validate a token or login), and
store the result as an
Authenticationin theSecurityContext. - 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 to create a book — a LIBRARIAN-only operation.
Before the controller, the request runs through Spring Security's ordered filter chain.
Bearer token is valid → authenticated as a LIBRARIAN.
Route needs ROLE_LIBRARIAN, and the user has it. Allowed.
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.
BookVault now uses Spring Security. For each case, say whether the response is 401 or 403, and why:
- A request with no credentials hits
GET /api/books. - 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.