Interview Questions
Spring Security Interview Questions and Answers
Spring Security questions tend to probe whether you understand the filter chain and the authentication/authorization distinction, not just whether you can copy-paste a config class.
Example: A basic security filter chain configuration
Java@Configuration
@EnableWebSecurity
public class SecurityConfig {
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
http
.authorizeHttpRequests(auth -> auth
.requestMatchers("/api/public/**").permitAll()
.requestMatchers("/api/admin/**").hasRole("ADMIN")
.anyRequest().authenticated()
)
.formLogin(Customizer.withDefaults())
.csrf(csrf -> csrf.disable()); // only for stateless APIs using tokens instead
return http.build();
}
@Bean
public PasswordEncoder passwordEncoder() {
return new BCryptPasswordEncoder();
}
}Frequently Asked Questions
Authentication answers "who are you" -- verifying an identity, usually via a username/password or a token. Authorization answers "what are you allowed to do" -- checking whether an already-authenticated identity has permission for a specific action or resource. Spring Security handles both, but they're distinct concerns configured separately.
Every request passes through a chain of servlet filters before reaching your controller -- filters that check for a session, validate a JWT, enforce CSRF protection, and more. Each filter can short-circuit the chain (e.g. rejecting an unauthenticated request) or pass control to the next filter. Understanding that this is filter-based, not annotation-based, is key to debugging why a request is or isn't reaching your code.
CSRF protection defends against a browser being tricked into submitting a request using a logged-in user's session cookie. It matters for cookie/session-based authentication. A stateless API authenticated via a bearer token in the Authorization header isn't vulnerable to classic CSRF the same way, since an attacker's page can't read or attach that header -- so CSRF protection is commonly disabled for such APIs (though the specifics depend on exactly how tokens are stored and transmitted).
PasswordEncoder implementations like BCryptPasswordEncoder hash a password with a random salt before storing it, and verify a login attempt by hashing the submitted password with the stored salt and comparing hashes -- the plain password is never stored. BCrypt is deliberately slow (configurable "work factor"), which makes brute-force attacks against stolen hashes far more expensive.
Beyond URL-based rules in the filter chain, @PreAuthorize("hasRole('ADMIN')") lets you secure individual service or controller methods directly, evaluated before the method runs. It requires @EnableMethodSecurity on your configuration class, and supports full SpEL expressions for more complex rules than simple role checks.
It's the interface Spring Security calls to load a user's details (username, password hash, authorities/roles) during authentication, typically backed by a database lookup. You implement loadUserByUsername(String username) to return a UserDetails object; Spring Security handles comparing the submitted credentials against it.
You'd configure the app as stateless (SessionCreationPolicy.STATELESS), add a custom filter that reads the Authorization: Bearer <token> header, validates the JWT's signature and expiry, and populates the SecurityContext with the resulting authentication -- all before the request reaches your controller. No server-side session is created; every request re-authenticates via the token itself.