Spring Security interview questions & answers

The fastest way to understand what Spring Security is for is to add nothing and watch what happens.

The demo below is a complete application: one @SpringBootApplication class, one @GetMapping("/hello") that returns a string. There is no security configuration in it - no config class, no annotations, no filter. The only thing that changed is that Spring Security's jars are on the classpath.

The output is the whole lesson. With no credentials the endpoint answers 401. With the right username and password it answers 200. With the right username and a wrong password it answers 401 again. None of that behaviour was written by the developer.

What actually turned on

Three separate things happened at startup, and each has a name an interviewer will expect:

1. A bean called springSecurityFilterChain appeared. That is the entry point for every secured request - the next topic takes it apart.
2. An in-memory user was created. Normally Boot generates a random password and prints it in the log; the demo pins the username and password with spring.security.user.* so the test is repeatable.
3. HTTP Basic authentication was enabled, which is why a browser or an HTTP client can send credentials at all.

The bean count in the output makes the size of that visible: 206 beans in an application whose source is two methods. Spring Boot registers those beans because Security's classes are on the classpath - the same @ConditionalOnClass mechanism the Spring Boot chapter measured. Boot's own numbers back this up: on a plain web app that count was 156, and adding the Security jars alone took it to 286.

Authentication and authorization are two different questions. Authentication asks who are you and produces an Authentication object. Authorization asks are you allowed to do this and produces a yes or no. Almost every confusing result in this chapter comes from answering the wrong one - the 401-vs-403 topic is entirely about that.

Why use the framework instead of writing a filter

Writing your own filter that checks a header looks like a fifty-line job, and for the happy path it is. The part that is not fifty lines is everything around it: hashing and upgrading passwords, not leaking whether a username exists, CSRF for cookie-based flows, session fixation, the default security headers, and returning the right status code in the right situation. Each of those is a whole topic in this chapter, and each one is something Spring Security already does.

When to use it: any Spring application that has users, roles, tokens, or an admin area - which is nearly every backend a job description will mention. It is also the answer interviewers expect: not "I wrote a filter", but "I configured a SecurityFilterChain".

Trade-off: the cost is that the defaults are invisible. Nothing in your source says the endpoint is protected, and nothing says CSRF is on. That is exactly why this chapter measures instead of describing - and why the next topic starts by printing the filter chain rather than talking about it.

The modern shape of configuration is a SecurityFilterChain bean built from HttpSecurity. If you read an older tutorial that extends WebSecurityConfigurerAdapter, that class is gone in Spring Security 6 - saying so is itself a common interview checkpoint.

// ---- smoke/Smoke.java ----
package smoke;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.ConfigurableApplicationContext;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@SpringBootApplication
@RestController
public class Smoke {

  @GetMapping("/hello")
  public String hello() { return "hello"; }

  // NOTE: there is no security configuration anywhere in this file.

  public static void main(String[] args) throws Exception {
    System.setProperty("server.port", "0");
    // Boot generates a random password and logs it. Pinned here so the test repeats.
    System.setProperty("spring.security.user.name", "waquar");
    System.setProperty("spring.security.user.password", "s3cret");

    try (ConfigurableApplicationContext ctx = SpringApplication.run(Smoke.class, args)) {
      int port = Integer.parseInt(ctx.getEnvironment().getProperty("local.server.port", "0"));

      // status(port, path, basicCredentials) does one real HTTP call
      System.out.println("  /hello  no creds        -> " + status(port, "/hello", null));
      System.out.println("  /hello  waquar:s3cret   -> " + status(port, "/hello", "waquar:s3cret"));
      System.out.println("  /hello  waquar:wrong    -> " + status(port, "/hello", "waquar:wrong"));

      System.out.println("  springSecurityFilterChain bean present = "
          + ctx.containsBean("springSecurityFilterChain"));
      System.out.println("  total beans = " + ctx.getBeanDefinitionCount());
    }
  }
}

Spring Security is not a layer inside your controller. It is a chain of servlet filters that runs before your controller, and almost every surprising result in this chapter is explained by that one sentence.

The path a request takes has three named parts, and interviewers ask for them in order:

1. DelegatingFilterProxy - a plain servlet filter registered with the servlet container. The container knows nothing about Spring beans, so this proxy is the bridge: it looks up a Spring bean and delegates to it.
2. FilterChainProxy - that bean. It holds a list of SecurityFilterChain objects and picks the first one whose matcher matches the request.
3. SecurityFilterChain - one chain: a matcher plus an ordered list of filters that actually do the work.

The demo prints all of it rather than describing it. It declares two chains - one matching /api/**, one matching everything else - and then walks FilterChainProxy.getFilterChains() and prints every filter's class name.

Read the two chains side by side

Both chains have 11 filters, but they are not the same 11, and the difference is the whole point:

• The /api/** chain has a BasicAuthenticationFilter and no CsrfFilter - because that chain declared httpBasic() and csrf().disable().
• The catch-all chain has a CsrfFilter and no BasicAuthenticationFilter - because it declared neither.

So the filter list is not a fixed thing you memorise. It is generated from your configuration, and this chapter has now measured three different counts in three configurations: 12 filters on a chain with HTTP Basic and CSRF left on, 11 on each of the two chains above, and 11 again once a custom filter was added and CSRF disabled. Quoting any one of those as "the number of filters in Spring Security" is wrong - not because the number is wrong, but because the question has no fixed answer. "That config produced 11, and here is how I printed them" is an answer that cannot be faked.

The order is the part that bites

Across both chains the order is stable and worth learning:

DisableEncodeUrl -> WebAsyncManagerIntegration -> SecurityContextHolder -> HeaderWriter -> (Csrf) -> Logout -> (BasicAuthentication) -> RequestCacheAware -> SecurityContextHolderAwareRequest -> AnonymousAuthentication -> ExceptionTranslation -> Authorization

Three consequences follow directly from that list:

• CsrfFilter runs before BasicAuthenticationFilter. A request can be rejected for CSRF before its credentials are ever checked, so valid credentials do not rescue a tokenless POST. Which status then reaches the client is a separate question - the CSRF topic measures a 401 that is really a protected /error page answering CsrfFilter's 403, not a consequence of this order.
• AuthorizationFilter is last. Authorization can only run once identity exists, which is why role checks are the final gate rather than the first one.
• ExceptionTranslationFilter sits just before it. It is the thing that turns an AuthenticationException into 401 and an AccessDeniedException into 403 for everything after it. Filters that run earlier write their own status - CsrfFilter answers a missing token with 403 without ever reaching it.

When to use multiple chains: when one application serves both a stateless JSON API and a browser UI. Give the API chain a securityMatcher("/api/**") with CSRF disabled and token authentication, and let a second chain handle the browser side with CSRF on and form login. @Order decides which is consulted first, and the first match wins - a catch-all chain placed first will swallow every request and the specific chain will never run.

Trade-off: filters are cheap but they are not free, and more importantly they are invisible in your source. Because security runs before the dispatcher servlet, a security failure never reaches your controller - which means @ControllerAdvice and ProblemDetail do not shape a 401 or a 403. Customising those responses needs an AuthenticationEntryPoint or an AccessDeniedHandler, which is a later topic in this chapter.

// ---- t2/T2.java ----
package t2;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.ConfigurableApplicationContext;
import org.springframework.context.annotation.Bean;
import org.springframework.core.annotation.Order;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.web.FilterChainProxy;
import org.springframework.security.web.SecurityFilterChain;
import org.springframework.web.bind.annotation.*;
import jakarta.servlet.Filter;

@SpringBootApplication
@RestController
public class T2 {
  @GetMapping("/api/data") public String api() { return "data"; }
  @GetMapping("/page")     public String page() { return "page"; }

  @Bean @Order(1)                       // first chain: only /api/**
  SecurityFilterChain apiChain(HttpSecurity http) throws Exception {
    return http.securityMatcher("/api/**")
        .csrf(c -> c.disable())
        .authorizeHttpRequests(a -> a.anyRequest().authenticated())
        .httpBasic(b -> {})
        .build();
  }

  @Bean @Order(2)                       // second chain: everything else
  SecurityFilterChain webChain(HttpSecurity http) throws Exception {
    return http.authorizeHttpRequests(a -> a.anyRequest().permitAll()).build();
  }

  public static void main(String[] args) {
    System.setProperty("server.port", "0");
    try (ConfigurableApplicationContext ctx = SpringApplication.run(T2.class, args)) {
      FilterChainProxy proxy = ctx.getBean("springSecurityFilterChain", FilterChainProxy.class);
      System.out.println("total chains = " + proxy.getFilterChains().size());
      int i = 0;
      for (var chain : proxy.getFilterChains()) {
        System.out.println("chain[" + i + "] filters=" + chain.getFilters().size());
        for (Filter f : chain.getFilters()) System.out.println("    " + f.getClass().getSimpleName());
        i++;
      }
    }
  }
}

This is the chapter's entry project, and it is deliberately not a new application. The Spring Data JPA chapter built a job board - companies, jobs, search with paging, close a job - and it had no authentication at all. Anyone who could reach the API could post a job or close someone else's. This project puts the lock on.

That is also the order an interview asks in: you built the API, you wired the database, how did you secure it?

The one honest difference from the previous chapter

The JPA chapter ran with no web layer; this chapter has a web layer and no database. So the entities here are a record in a Map rather than JPA entities. Nothing about the security is affected by that - the filter chain does not know or care what is behind the controller - but do not read this file as a replacement for the persistence work. The two halves are deliberately taught in the chapters that can actually run them.

The rules, and why each one is shaped that way

.requestMatchers(HttpMethod.GET,    "/api/jobs").permitAll()
.requestMatchers(HttpMethod.POST,   "/api/jobs").hasRole("RECRUITER")
.requestMatchers(HttpMethod.DELETE, "/api/jobs/**").hasRole("ADMIN")
.anyRequest().authenticated()

The matchers are method-aware. GET /api/jobs and POST /api/jobs are the same path with two completely different permissions, which is normal for a real API - reading a job feed is public, publishing to it is not. A path-only matcher cannot express that.

The order is specific to general. Each rule is narrower than the one after it, and anyRequest() is last. Written the other way round the application would not start - the authorizing-requests topic measures that.

The last line is a whitelist. anyRequest().authenticated() means /api/jobs/mine, which no rule mentions, is closed to anonymous callers by default. When someone adds /api/jobs/{id}/applicants next month and forgets the security config, it will be closed too. That is the entire argument for ending with authenticated().

csrf.disable() plus STATELESS is correct here and only because of the credential: HTTP Basic arrives in a header the browser never attaches by itself. Move the credential into a cookie and both decisions become wrong.

What the run proves

GET    /api/jobs        anonymous -> 200  []
POST   /api/jobs        anonymous -> 401
POST   /api/jobs        asha USER -> 403
POST   /api/jobs        rec  REC  -> 200  {"id":1,...,"postedBy":"rec"...}
GET    /api/jobs/mine   rec  REC  -> 200  [ {"id":1,...} ]
GET    /api/jobs/mine   asha USER -> 200  []
DELETE /api/jobs/1      rec  REC  -> 403
DELETE /api/jobs/1      boss ADM  -> 200  deleted

Read rows two and three together - they are the whole 401-versus-403 lesson in the shape it actually appears. The same POST, refused twice for different reasons: nobody gets 401, the wrong somebody gets 403.

And rows five and six: the same endpoint, the same status, different data. /api/jobs/mine is not protected by a rule at all - it is protected by the controller using Authentication.getName() to filter. That distinction matters: authorization rules decide whether you may call something; only your code can decide which rows you are allowed to see. A rule can never express "your own jobs".

Build it yourself

1. Three users with BCrypt-encoded passwords - a candidate, a recruiter, an admin. Never {noop} outside a demo.
2. The four rules above. Verify each one from two sides: the role that should pass and a role that should not.
3. GET /api/jobs/mine filtered by Authentication.getName().
4. Then break it on purpose and watch: change hasRole("RECRUITER") to hasAuthority("RECRUITER") and see every post fail with 403, because the stored authority is ROLE_RECRUITER.

When to use this shape: any API with public reads and privileged writes, which is most of them. Coarse rules on the chain, row-level decisions in code.

When NOT to: do not try to express ownership in authorizeHttpRequests. "Only the recruiter who posted this job may close it" is not a URL rule - it is either a @PreAuthorize with the argument, or a check in the service. Twisting matchers into ownership rules produces configuration nobody can read and holes nobody can see.

Trade-off: these rules are readable precisely because they are coarse, and coarse rules cannot protect a service method reached from a scheduled job or a second controller. That is the gap the next two projects and the method-security topic cover.

// ---- p16/P16.java ----
// Ch9 ka Job - bina JPA ke, kyunki is chapter ke env me koi DB nahi hai.
record Job(Long id, String title, String city, String postedBy, String status) {}

@GetMapping("/api/jobs")                                   // public feed
public Collection<Job> feed() { return JOBS.values(); }

@PostMapping("/api/jobs")                                  // recruiter only
public Job post(@RequestParam String title, @RequestParam String city, Authentication a) {
  long id = SEQ.incrementAndGet();
  Job j = new Job(id, title, city, a.getName(), "OPEN");   // owner = the caller
  JOBS.put(id, j);
  return j;
}

@GetMapping("/api/jobs/mine")                              // any logged-in user
public List<Job> mine(Authentication a) {
  return JOBS.values().stream().filter(j -> j.postedBy().equals(a.getName())).toList();
}

@DeleteMapping("/api/jobs/{id}")                           // admin only
public String delete(@PathVariable Long id) {
  return JOBS.remove(id) == null ? "not-found" : "deleted";
}

@Bean
SecurityFilterChain chain(HttpSecurity h) throws Exception {
  return h
      .csrf(c -> c.disable())                              // credential is a header, not a cookie
      .sessionManagement(s -> s.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
      .authorizeHttpRequests(a -> a
          .requestMatchers(HttpMethod.GET,    "/api/jobs").permitAll()
          .requestMatchers(HttpMethod.POST,   "/api/jobs").hasRole("RECRUITER")
          .requestMatchers(HttpMethod.DELETE, "/api/jobs/**").hasRole("ADMIN")
          .anyRequest().authenticated())                   // whitelist default
      .httpBasic(b -> {})
      .build();
}

@Bean PasswordEncoder enc() { return new BCryptPasswordEncoder(); }

@Bean UserDetailsService users(PasswordEncoder e) {
  return new InMemoryUserDetailsManager(
      User.withUsername("asha").password(e.encode("pw1")).roles("USER").build(),
      User.withUsername("rec").password(e.encode("pw2")).roles("RECRUITER").build(),
      User.withUsername("boss").password(e.encode("pw3")).roles("ADMIN").build());
}