security

Spring Security Basics

Wire authentication, authorization, and common HTTP defenses (CSRF, headers, CORS) declaratively via a SecurityFilterChain.

Spring Security secures an application by inserting a chain of servlet filters in front of your controllers, so every request is authenticated and authorised before it reaches your code. Rolling your own security is notoriously easy to get subtly and dangerously wrong; Spring Security provides battle-tested implementations of authentication, authorisation, and the common HTTP defences, wired declaratively.

Building security: a single front desk that checks badges, lets you into specific floors, and tracks where you go. Add it once, every door inherits the policy.

Key Concepts

1
The central abstraction in modern Spring Security is the SecurityFilterChain bean, configured with a fluent DSL. There you declare which URL patterns are public and which require authentication or specific roles (authorizeHttpRequests), choose the authentication mechanism (form login, HTTP Basic, or a bearer-token resource server), and configure protections. Two concepts underpin it: authentication establishes who the caller is, producing an Authentication stored in the SecurityContext; authorisation then decides whether that principal may perform the requested action, by URL rule or by role/authority. Spring Security also turns on sensible HTTP hardening by default — CSRF protection for browser sessions, security response headers, and session-fixation defences — and integrates CORS configuration for cross-origin browser clients.
SecurityFilterChainauthorizeHttpRequestsAuthenticationSecurityContext
2
The distinctions interviewers probe are authentication versus authorisation (who you are versus what you may do), and when CSRF protection matters. CSRF defends cookie/session-based browser flows, where the browser auto-attaches credentials; for a stateless token-based API where the client sends an explicit bearer token, CSRF is typically disabled because the attack it prevents does not apply. The practical guidance is to configure the filter chain explicitly, default to denying access and opening up only what should be public, and avoid hand-rolling crypto or session handling that the framework already does correctly.