What is Spring Security?

Think of Spring Security as the bouncer at the door of your app: it checks who you are, what you may enter, and blocks everyone else before the controller even sees the request.

Question: What is Spring Security?

Answer: Spring Security is the security framework for Spring and Spring Boot. It handles authentication (proving identity) and authorization (deciding access), and it does that mostly through a chain of servlet filters that runs before your business code. In Spring Boot, adding the security starter protects your app by default, then you customize which endpoints are public, which need a login, and which need roles.

Interview-Ready Answer: Spring Security is the framework I use in Spring Boot to protect requests before they reach my controllers. It authenticates users, authorizes access with roles or permissions, and can also handle login, logout, CSRF protection, and session management. One detail I like is that it works through a filter chain, so the security decision happens early and consistently for every request.

What it really is

Spring Security is the security layer that sits in front of your web app. On the servlet stack, it is built around filters, which are small request interceptors that can inspect, reject, or enrich a request before it reaches a controller. The current user is stored in a SecurityContext (a holder for the current authentication), and Spring Boot wires sensible defaults when the security starter is present.

How the request flow works

1. The incoming HTTP request hits the servlet filter chain before DispatcherServlet and your controller.
2. Spring Security looks for existing authentication in SecurityContextHolder, which uses a ThreadLocal (per-thread storage) so the current request thread can remember the user without passing it through every method.
3. If the request includes credentials such as a session cookie, form login data, HTTP Basic headers, a bearer token, or an OAuth2 login response, an authentication filter delegates to an AuthenticationManager and one or more AuthenticationProvider implementations to verify them.
4. On success, Spring stores an Authentication object in the SecurityContext. On failure, it returns 401 Unauthorized or redirects to a login page, depending on the configured entry point.
5. Authorization rules run next. They check the path, HTTP method, roles, and authorities. If the user is authenticated but not allowed, Spring returns 403 Forbidden.
6. Only after those checks pass does your controller run. At the end of the request, the context is cleared so one request cannot leak its user into another thread.

Authentication vs Authorization

When and why to use it

• Use it whenever your app has users, private data, admin actions, or any endpoint that should not be open to everyone.
• Use it for browser apps, REST APIs, and method-level security such as @PreAuthorize.
• It prevents common mistakes like plain-text passwords, missing access checks, and home-grown security code that is easy to bypass.

Performance and version notes

• Per request, the authorization checks are usually close to O(1): a small, constant amount of filter work and rule matching.
• Password hashing is intentionally expensive. BCryptPasswordEncoder uses a cost factor of 10 by default, and a single password check often takes tens to hundreds of milliseconds depending on hardware and configuration. That slowness is a feature, because logins are rare and brute-force attacks become costly.
• If you use session-based login, the server keeps the SecurityContext in the HTTP session. If you use token-based auth, each request carries its own proof, which is common for stateless APIs.
• Spring Security 6 removed WebSecurityConfigurerAdapter; the modern style is to define a SecurityFilterChain bean.

Important edge cases

• permitAll() does not bypass the filter chain; it only says the request is allowed through authorization.
• web.ignoring() skips the security chain completely, so use it sparingly, usually only for static assets.
• hasRole("ADMIN") expects the logical role name. Spring adds the ROLE_ prefix when you use roles("ADMIN") in user setup.
• A 403 can come from missing permission or from CSRF protection on a state-changing request, so do not assume every 403 is a role problem.

Real-World Story: Imagine an e-commerce checkout service deployed to Kubernetes. The team adds Spring Security and forgets that /actuator/health is called by the load balancer without a login. Suddenly the health probe gets 401 Unauthorized responses, pods turn Unready, the autoscaler restarts them, and checkout traffic starts failing with 503 Service Unavailable. Logs show repeated unauthenticated health checks even though the app works locally in a browser because the developer is already logged in.

The bug is not in the controller code; it is in the security rule set. The fix is to explicitly allow the health endpoint or place actuator routes in a separate security configuration. This is exactly why interviewers like Spring Security: a tiny rule can protect your app or take production down if it is wrong.

Follow-up & Tricky Questions:

• How are authentication and authorization different? Authentication proves identity; authorization decides access. In Spring Security, login or token validation gives you an Authentication, and access rules like hasRole decide whether the request may continue.
• What is SecurityFilterChain? It is the bean that defines how Spring Security filters and authorizes requests. In Spring Security 6+, it is the standard replacement for the old adapter-based configuration style.
• How would you secure a REST API differently from a browser app? For APIs, I usually prefer stateless auth such as JWT or OAuth2 resource server, often with HTTP Basic only for simple internal tools. Browser apps more often use form login and server sessions.
• What is SecurityContext? It is the container for the current Authentication. Spring stores it in SecurityContextHolder so controllers and services can ask who the current user is.
• Why do we need PasswordEncoder? Because plain-text passwords are unsafe. A PasswordEncoder hashes passwords and verifies them safely, and BCrypt is the common default choice.
• What happens when access is denied? If the user is not logged in, Spring typically returns 401 or a login page; if the user is logged in but lacks permission, it returns 403.
• Does permitAll() remove security? No. It only allows authorization to pass for that route; the request still goes through the security filter chain.
• Does hasRole("ADMIN") check for ADMIN or ROLE_ADMIN? It checks the logical role name ADMIN, while Spring typically stores it as ROLE_ADMIN under the hood when you use roles("ADMIN").
• Is Spring Security only for login pages? No. It also secures APIs, method calls, CSRF, logout, session management, OAuth2 login, and more.

Common gotcha questions:

• If I add the security starter, are my endpoints public? No. The opposite happens: Spring Boot protects everything by default until you explicitly allow routes.
• Why can a logged-in user still get 403? Because being authenticated does not mean being authorized. The user is known, but the role or authority check failed.
• Can a 403 mean CSRF instead of roles? Yes. On POST, PUT, PATCH, or DELETE requests in browser-session apps, CSRF protection can reject requests that do not carry a valid token.

Common Mistakes:

• Thinking Spring Security is only a login page. Correction: it is a full security framework for authentication, authorization, CSRF, sessions, and more.
• Confusing 401 with 403. Correction: 401 means not authenticated, while 403 means authenticated but not allowed.
• Storing plain-text passwords. Correction: always use a PasswordEncoder, with BCrypt as the common default.
• Using old tutorials that extend WebSecurityConfigurerAdapter. Correction: in Spring Security 6, define a SecurityFilterChain bean instead.

Memory Hook: Spring Security is the club door: authentication checks your ID, authorization checks your wristband.

Cheat Sheet:

• Spring Security protects Spring apps before controllers run.
• Authentication = who you are.
• Authorization = what you can access.
• Spring Boot secures everything by default when the security starter is present.
• The current user lives in the SecurityContext.
• BCrypt hashes passwords; do not store them in plain text.

Practice Tasks:

• Add a /user endpoint and allow both USER and ADMIN roles to call it.
• Switch the in-memory users to a database-backed UserDetailsService and keep the same access rules.
• Add a POST endpoint and observe how CSRF behaves, then learn when it should be kept on or disabled.