Top Spring Security Interview Questions & Answers
This guide compiles the most challenging and frequently asked Spring Security interview questions. It covers core security concepts, OAuth2 integration, CSRF/CORS configurations, and scenario-based debugging.
1. Core Spring Security Concepts
Q: Explain SecurityContext and SecurityContextHolder in Spring Security.
A: * SecurityContext: This is where the details about the currently authenticated user are stored, such as the user's principal details and granted authorities (roles/permissions).
SecurityContextHolder: This is a helper class that holds theSecurityContext. It acts as a container or storage space that tracks the authentication information of the current user throughout the application's lifecycle. It usesThreadLocalby default, making it easy to access the user's details anywhere in the application to make security decisions.
Q: Explain what AuthenticationManager and ProviderManager are in Spring Security.
A: * AuthenticationManager: It is the core interface acting like a checkpoint that determines if a user's login details are correct.
ProviderManager: It is the most common implementation ofAuthenticationManager. It delegates the actual authentication process to a list of configuredAuthenticationProviders. It iterates through this list (e.g., a database provider, an LDAP provider) to find one that supports the authentication token and can validate the user.
Q: Explain the purpose of a Spring Security Filter Chain and how you would add or customize a filter.
A: The Spring Security Filter Chain is a sequence of filters that handles all authentication and authorization processes in a Spring application. Each filter has a specific task, such as checking login credentials or verifying session tokens.
To add or customize a filter, you define a new filter class (e.g., extending OncePerRequestFilter) and add it to the chain in your security configuration using methods like addFilterBefore(), addFilterAfter(), or addFilterAt(). This specifies exactly where in the chain your custom logic should execute.
2. Web Security: CORS, CSRF, & Passwords
Q: Explain Cross-Origin Resource Sharing (CORS) and how you would configure it in a Spring Boot application.
A: CORS is a security mechanism that allows a website to safely access resources from another website (domain). In Spring Boot, you can set up CORS by:
- Adding the
@CrossOriginannotation directly to specific REST controllers or methods. - Configuring it globally by defining a
WebMvcConfigurerbean and overriding theaddCorsMappings()method. This tells the application which external domains can use its resources, what HTTP methods they can use, and which headers are allowed.
Q: How does Spring Security protect against Cross-Site Request Forgery (CSRF) attacks, and when might you disable it?
A: Spring Security protects against CSRF by generating a unique, unpredictable token for each session. It requires that every state-changing request (POST, PUT, DELETE) from the client includes this token, ensuring the request was intentionally made by the authenticated user and not a malicious third-party site. When to disable: You typically disable CSRF protection for stateless APIs (like REST APIs secured with JWT) that are meant to be accessed by non-browser clients (like mobile apps or backend-to-backend services), because they do not rely on browser cookies for authentication.
Q: What is Digest Authentication?
A: Digest authentication is a method used to verify a user's identity without sending their actual password in plain text over the internet. Instead, the client sends a hashed (scrambled) version of the password combined with a server-provided "nonce" (a one-time number). The server performs the same calculation and compares the hashes. If they match, access is granted.
Q: What is the best practice for storing passwords in a Spring Boot application?
A: The absolute best practice is to never store plain text passwords. Passwords should be hashed using a strong, computationally heavy, one-way hashing algorithm like BCrypt, which Spring Security supports natively via BCryptPasswordEncoder.
Q: Explain "Salting" and its uses in Spring Security.
A: Salting means adding a random sequence of characters (the salt) to a password before running it through a hashing algorithm. Use: It makes every user's password hash completely unique, even if two users share the exact same password. This protects the database against pre-computed dictionary attacks and "rainbow table" lookups. BCrypt handles salting automatically.
3. Authorization & Access Control
Q: How can you implement Method-Level Security in a Spring application and what are its advantages?
A: You enable it using the @EnableMethodSecurity annotation on a configuration class. Then, you use annotations like @PreAuthorize, @PostAuthorize, or @Secured directly on individual methods.
Advantages: It provides fine-grained control over who can access specific functionalities, moving security logic directly to the business layer. It ensures that even if a web endpoint is somehow bypassed, the underlying service method remains strictly protected.
Q: How can you use Spring Expression Language (SpEL) for fine-grained access control?
A: You can embed SpEL directly inside security annotations like @PreAuthorize. For example, you can write expressions to check if a user has a specific role (hasRole('ADMIN')), evaluate multiple permissions (hasAuthority('READ') and hasRole('USER')), or even match the authenticated user's ID against the method's arguments (@PreAuthorize("#userId == authentication.principal.id")). This allows for dynamic, context-sensitive security rules.
Q: Describe how to implement Dynamic Access Control policies in Spring Security.
A: Beyond static roles, you can implement dynamic policies by writing custom SpEL expressions or custom bean methods. For example, you can use @PreAuthorize("@securityService.canAccessResource(authentication, #resourceId)"). At runtime, Spring will call your custom securityService bean, which could fetch permissions from a live database to dynamically decide if the current user should be granted access.
Q: In your application, there are 'ADMIN' and 'USER' roles. How would you configure Spring Security to enforce access controls based on these roles?
A: In the Security Configuration chain, I would define URL pattern matchers using requestMatchers().
For example:
http.authorizeHttpRequests(auth -> auth
.requestMatchers("/admin/**").hasRole("ADMIN")
.requestMatchers("/user/**").hasAnyRole("USER", "ADMIN")
.anyRequest().authenticated()
);
This ensures that all paths under /admin are strictly locked to admins, while /user endpoints are accessible to standard users.
4. OAuth2 & Architecture Integration
Q: How does Spring Security integrate with OAuth2 for authorization?
A: Spring Security acts as an OAuth2 Client. When a user tries to access a protected resource, Spring Security redirects them to an external OAuth2 Provider (like Google, GitHub, or Okta) for login. After successful authentication, the provider issues an Access Token back to Spring Security. Spring Security then uses this token to verify the user's permissions, establish a secure session, and grant access to the requested resources.
Q: What do you mean by the OAuth2 "Authorization Code" Grant type?
A: It is the most secure and common OAuth2 flow used for server-side applications.
- The user is redirected to the provider's login page.
- Upon logging in, the provider redirects back to the application with a temporary "Authorization Code".
- The application's backend server securely exchanges this code for an "Access Token" directly with the provider. This prevents the actual access token from ever being exposed to the user's browser, significantly minimizing security risks.
Q: Your organization uses an API Gateway to route requests to microservices. How would you leverage Spring Security at the Gateway level?
A: I would configure Spring Security at the API Gateway to handle all initial authentication (e.g., verifying JWTs or handling the OAuth2 login flow). By validating tokens and roles at the Gateway, I ensure that only clean, authorized requests are forwarded to the downstream microservices. This offloads security overhead from the individual services, making the entire distributed system simpler and more efficient.
5. Session Management, Debugging & Testing
Q: How does Spring Security handle session management and what are the options for concurrent sessions?
A: Upon successful authentication, Spring Security creates an HTTP session. To manage concurrent sessions, you can configure SessionManagement rules. For example, you can set maximumSessions(1) to limit a user to a single active login. You can further configure it to either prevent the new login attempt (maxSessionsPreventsLogin(true)) or automatically invalidate their oldest active session.
Q: When a user lacks permissions, you want to redirect them to a custom "Access Denied" page instead of the default error message. How would you achieve this?
A: I would configure the Exception Translation Filter within my security configuration. I would implement a custom AccessDeniedHandler and register it using .exceptionHandling(e -> e.accessDeniedHandler(myCustomHandler)). This handler intercepts the AccessDeniedException and securely redirects the user to the custom URL, providing a much better user experience.
Q: You encounter an issue where users are unexpectedly denied access to a resource. Describe your approach to debugging this.
A: 1. Verify the Security Configuration rules (requestMatchers) and method-level annotations to ensure the required roles match the user's actual assigned authorities.
2. Enable debug-level logging for Spring Security (logging.level.org.springframework.security=DEBUG in application.properties). This prints the entire filter chain execution and exact reasons for access denial in the console.
3. Check the SecurityContext at runtime to ensure the user is correctly authenticated and hasn't lost their session.
Q: How do you test security configurations in a Spring application?
A: I use Spring Security's testing module (spring-security-test).
- I write integration tests using
MockMvcto hit secured endpoints. - I use annotations like
@WithMockUser(roles = "ADMIN")to simulate an authenticated admin, or@WithAnonymousUserto simulate a guest. - I then assert that the endpoint correctly returns
200 OKfor authorized users and401 Unauthorizedor403 Forbiddenwhen the rules dictate they should be blocked.