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.
3
What the interviewer is probing.
What the interviewer is probing.
4
1. "How does the filter chain work?" *Probing:* the model. *Stalls:* "A filter." *Moves up:* an
ordered chain of servlet filters, each handling one concern, building an Authentication into the
SecurityContext.
1. "How does the filter chain work?"
5
2. "How is authorisation expressed today?" *Probing:* currency. *Stalls:* "antMatchers." *Moves
up:* the lambda DSL with requestMatchers and authorizeHttpRequests — the older adapter and
antMatchers style is removed.
2. "How is authorisation expressed today?"
6
3. "Why disable CSRF for a stateless API?" *Probing:* the reasoning. *Stalls:* "It is easier."
*Moves up:* CSRF exploits ambient cookie credentials; a token in an Authorization header is not sent
automatically, so the attack does not apply.
3. "Why disable CSRF for a stateless API?"
7
4. "What is the most common misconfiguration?" *Probing:* experience. *Stalls:* "None." *Moves
up:* matcher order — a permitAll pattern placed before a more specific authenticated rule opens the
endpoint.
4. "What is the most common misconfiguration?"