Foundations: What Is Security, and Why Should You Care?
Every later chapter assumes you already know what a Filter is and why authentication and authorization are two different questions. This chapter is that foundation, built from zero prior security knowledge.
Learning objectives
- Beginner: State the difference between authentication and authorization in one sentence each.
- Intermediate: Trace how a servlet Filter can intercept a request before it reaches your controller.
- Advanced: Explain why DelegatingFilterProxy exists as a bridge between the servlet container and the Spring ApplicationContext.
🌱 BEGINNER STORY
Imagine you own a bank branch. Every morning you unlock the front door for customers — anyone can walk in and read the brochures in the lobby (that's a PUBLIC page). But if a customer wants to withdraw cash, you don't just take their word for it. First you ask for an ID card to confirm WHO they are (this is AUTHENTICATION). Once you know it's really "John Doe", you still check your records to see WHAT John is allowed to do — maybe John can only operate his own savings account, but not touch someone else's locker, and definitely can't approve a new bank branch (this is AUTHORIZATION). Spring Security is simply the 'bank security guard + ID-checking clerk + rulebook' for your Java web application. It sits in front of every request and decides: (1) is this a public page anyone can see, (2) if not, who is this person, and (3) what are they allowed to do.
Every day, real companies lose money and reputation because of security holes that are almost always avoidable with frameworks like Spring Security. A few real patterns you will recognize once you start looking:
-
An e-commerce API forgets to check that the logged-in user actually owns the order they are cancelling — a competitor could cancel everyone else's orders just by changing an order ID in the URL (this class of bug is called IDOR / Broken Object Level Authorization).
-
A banking app stores passwords as plain text in the database — a single SQL injection or leaked backup exposes every customer's real password (and since people reuse passwords, this cascades into other services too).
-
A single-page app (Angular/React) calls a Spring Boot API on a different port, and nobody configures CORS correctly — so either the browser blocks legitimate calls, or worse, it's opened up so wide that any website on the internet can call the API using the victim's cookies.
-
A hidden HTML form on a malicious website silently submits a money-transfer request to a bank website where the victim is already logged in — this is CSRF, and it works precisely because browsers automatically attach cookies to every request to that domain.
Spring Security exists to solve exactly these categories of problems in a consistent, well-tested, configurable way — so that you, as a developer, don't have to hand-roll fragile security logic for every single project.
Authentication (AuthN): The process of proving identity — "Who are you?" In Spring Security this typically means checking a username/password, validating a JWT signature, or trusting an OAuth2 identity provider.
Authorization (AuthZ): The process of deciding what an already-identified user is allowed to do — "What can you access?" This is enforced using Roles and Authorities, method-level annotations like @PreAuthorize, and URL-matcher rules.
Figure: Authentication confirms identity; Authorization decides permissions — like an ATM checking your PIN, then checking your account balance rules.
✅ Remember it this way
AuthentiCATION = identifiCATION (who). AuthoriZATION = permiSSION (what). If a request fails with HTTP 401 Unauthorized, that's actually an AUTHENTICATION problem ("I don't know who you are"). If it fails with HTTP 403 Forbidden, that's an AUTHORIZATION problem ("I know who you are, but you can't do this"). This mix-up shows up constantly in interviews and in real bug reports — get it right early.
🌱 BEGINNER STORY
Think of your web application like an airport terminal. A passenger (HTTP request) doesn't walk directly onto the plane (your Controller/Servlet). They pass through a series of checkpoints in a fixed order: check-in counter, security scanner, passport control, boarding gate. Each checkpoint can either let the passenger through to the next one, or stop them right there and send them back. In Java web applications, these checkpoints are called Filters, and the plane is the Servlet (in Spring MVC, the DispatcherServlet, which routes to your @RestController methods).
A Servlet is simply a Java class that handles an HTTP request and produces an HTTP response — in a typical Spring Boot app, you rarely write servlets yourself because Spring's DispatcherServlet is the single servlet that receives every request and forwards it to the right @Controller method.
A Filter is a Java class that can intercept a request BEFORE it reaches the servlet, and intercept the response AFTER the servlet is done — without the servlet needing to know the filter exists. Filters are chained together: each filter decides whether to call chain.doFilter(request, response) to pass control to the next filter (or the servlet), or to stop the chain entirely (for example, to reject an unauthenticated request).
Figure: A servlet filter chain: each filter can inspect/modify the request, call the next filter, and then inspect/modify the response on the way back.
Why This Matters For Spring Security
Spring Security is implemented ENTIRELY as a chain of servlet Filters (there is no magic beyond this). When your application starts, Spring Security registers a single filter called the FilterChainProxy inside the standard servlet filter chain (usually via a filter named springSecurityFilterChain). Internally, FilterChainProxy delegates to an ordered list of 10-20+ specialized security filters — one for CORS, one for CSRF, one for username/password login, one for exception translation, one for final authorization checks, and so on. Understanding 'it's just filters, in order, each with one job' demystifies almost everything else in this guide.
There's one subtlety worth understanding early: Spring Security beans (like your security configuration) live inside the SPRING application context, but the raw servlet Filter chain is managed by the SERVLET CONTAINER (Tomcat, embedded in Spring Boot), which knows nothing about Spring beans. The bridge between these two worlds is a class called DelegatingFilterProxy — it's a plain servlet Filter registered with the container, and its only job is to look up the actual Spring-managed filter chain bean (FilterChainProxy) and delegate every request to it. Spring Boot auto-configures this for you, so you never write it yourself, but knowing it exists explains how Spring beans (like your @Bean SecurityFilterChain) end up participating in raw servlet filtering.
⚠ Common real-world traps
Filter ORDER matters enormously. If a logging filter runs after the authentication filter, you might log data for requests that were already rejected — or worse, a custom filter placed in the wrong order might read raw passwords before they are ever validated. Static resources (CSS, JS, images) still pass through the entire filter chain unless explicitly excluded — a common performance/config mistake is applying full security filtering to publicly-servable static assets. Asynchronous requests (e.g. Spring WebFlux, or MVC async processing) can lose the SecurityContext across threads unless you explicitly propagate it — this trips up teams migrating to reactive stacks. Multiple SecurityFilterChain beans (introduced to support multiple independent security configs per URL pattern) must have a clear order via @Order — misconfigured ordering silently applies the wrong chain to a URL pattern.
Want a visual for this concept?
Generate a diagram tailored to “Foundations: What Is Security, and Why Should You Care?” — the AI picks whichever visual (flowchart, comparison, sequence, etc.) best fits.
Sign in to generate a visual →