Spring Security interview questions & answers

Spring Security kis liye hai, ye samajhne ka sabse tez tareeka hai — kuch bhi add mat kijiye, aur dekhiye hota kya hai.

Neeche wala demo ek poora application hai: ek @SpringBootApplication class, aur ek @GetMapping("/hello") jo ek string lautata hai. Isme koi security configuration nahi hai — na config class, na annotation, na filter. Sirf ek cheez badli hai: Spring Security ki jars classpath par hain.

Output hi poora sabak hai. Bina credentials ke endpoint 401 deta hai. Sahi username-password par 200. Sahi username par galat password dene par phir se 401. Ye bartaav developer ne likha hi nahi hai.

Asal me ON kya hua

Startup par teen alag cheezein hui, aur teenon ka naam interviewer aapse sunna chahta hai:

1. springSecurityFilterChain naam ka ek bean ban gaya. Har secured request usi se guzarti hai — agla topic use khol kar dekhta hai.
2. Ek in-memory user ban gaya. Aam taur par Boot ek random password banata hai aur use log me chhapta hai; demo ne spring.security.user.* se username-password pin kar diya hai taaki test dobara wahi nateeja de.
3. HTTP Basic authentication chalu ho gaya — isiliye koi browser ya HTTP client credentials bhej hi paata hai.

Output me bean ki ginti is poore kaam ka size dikhati hai: 206 beans, us application me jiska source do method ka hai. Boot ne ye beans isliye register ki kyunki Security ki classes classpath par hain — wahi @ConditionalOnClass wala mechanism jo Spring Boot chapter me naapa gaya tha. Boot ke apne numbers isi ki tasdeeq karte hain: ek saade web app par ginti 156 thi, aur sirf Security ki jars jodte hi 286 ho gayi.

Authentication aur authorization do alag sawaal hain. Authentication poochta hai aap kaun hain aur ek Authentication object banata hai. Authorization poochta hai aapko ijaazat hai ya nahi aur haan/naa deta hai. Is chapter ke lagbhag saare bharmane wale nateeje galat sawaal ka jawab dene se aate hain — 401-vs-403 wala topic poora isi par hai.

Khud filter likhne ke bajay framework kyun

Header check karne wala apna filter likhna pachaas line ka kaam lagta hai, aur happy path ke liye hai bhi. Pachaas line me jo nahi aata wo hai uske aas-paas ki har cheez: password hashing aur baad me algorithm upgrade karna, ye leak na hone dena ki username exist karta hai ya nahi, cookie wale flows ke liye CSRF, session fixation, default security headers, aur sahi mauke par sahi status code lautana. Inme se har ek is chapter ka apna topic hai, aur har ek Spring Security pehle se karti hai.

Kab use karein: har us Spring application me jisme users, roles, tokens ya admin area hai — yaani lagbhag har wo backend jo job description me likha hota hai. Interview me bhi jawab yahi expected hai: "maine filter likha tha" nahi, balki "maine SecurityFilterChain configure ki thi".

Trade-off kya hai: keemat ye hai ki defaults dikhte nahi. Aapke source me kahin nahi likha ki endpoint protected hai, aur kahin nahi likha ki CSRF ON hai. Isiliye ye chapter batata nahi, naapta hai — aur agla topic baat karne ke bajay seedha filter chain chhapta hai.

Configuration ka aaj ka roop HttpSecurity se bana hua SecurityFilterChain bean hai. Agar koi purana tutorial WebSecurityConfigurerAdapter extend karta dikhe, to wo class Spring Security 6 me hai hi nahi — ye bata dena khud ek aam interview checkpoint hai.

// ---- 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 aapke controller ke andar ki koi layer nahi hai. Wo servlet filters ki ek chain hai jo aapke controller se pehle chalti hai — aur is chapter ke lagbhag saare chaunkane wale nateeje isi ek vaakya se samajh aate hain.

Request ka raasta teen naam wale hisson se guzarta hai, aur interviewer inhe isi kram me sunna chahta hai:

1. DelegatingFilterProxy — ek saadha servlet filter jo servlet container me register hota hai. Container ko Spring beans ka kuch pata nahi hota, isliye ye proxy pul ka kaam karta hai: wo ek Spring bean dhoondh kar usse kaam karwata hai.
2. FilterChainProxy — wahi bean. Uske paas SecurityFilterChain objects ki list hoti hai aur wo pehli aisi chain chunta hai jiska matcher request se milta hai.
3. SecurityFilterChain — ek chain: ek matcher aur filters ki ek kram wali list, jo asal me kaam karti hai.

Demo ye sab batata nahi, chhapta hai. Usme do chain declare ki gayi hain — ek /api/** ke liye, ek baaki sabke liye — phir FilterChainProxy.getFilterChains() par chal kar har filter ka class naam chhapa gaya hai.

Dono chains ko saath me padhiye

Donon chains me 11 filter hain, par wo ek jaise 11 nahi hain — aur yahi poori baat hai:

• /api/** wali chain me BasicAuthenticationFilter hai aur CsrfFilter nahi, kyunki usme httpBasic() aur csrf().disable() likha tha.
• Catch-all chain me CsrfFilter hai aur BasicAuthenticationFilter nahi, kyunki usme dono me se kuch nahi likha tha.

Yaani filter ki list koi tay cheez nahi hai jo rat li jaaye. Wo aapki configuration se banti hai, aur is chapter ne ab teen alag configurations me teen alag gintiyan naap li hain: HTTP Basic ke saath aur CSRF chalu rehne par 12, upar wali dono chains par 11-11, aur custom filter jodne + CSRF band karne par phir se 11. Inme se kisi ek ko "Spring Security me itne filter hote hain" kehna galat hai — isliye nahi ki number galat hai, balki isliye ki sawaal ka koi tay jawab hai hi nahi. "Us config par 11 bane the, aur maine unhe aise chhapa tha" wo jawab hai jo bana kar nahi bola ja sakta.

Kram wala hissa hi kaatta hai

Dono chains me kram sthir hai aur seekhne laayak hai:

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

Is list se teen baatein seedhi nikalti hain:

• CsrfFilter BasicAuthenticationFilter se pehle chalta hai. Koi request credentials jaanche jaane se pehle hi CSRF par reject ho sakti hai, isliye sahi credentials bina token wale POST ko nahi bachate. Client tak phir kaunsa status pahunchta hai wo alag sawaal hai — CSRF wala topic ek aisa 401 naapta hai jo asal me protected /error page ka CsrfFilter ke 403 par diya gaya jawab hai, is kram ka nateeja nahi.
• AuthorizationFilter sabse aakhir me hai. Authorization tabhi chal sakta hai jab identity maujood ho — isiliye role check pehla nahi, aakhri darwaza hota hai.
• ExceptionTranslationFilter usse thoda pehle baitha hai. Wahi apne baad wali har cheez ke liye AuthenticationException ko 401 aur AccessDeniedException ko 403 banata hai. Jo filters pehle chalte hain wo apna status khud likhte hain — CsrfFilter token na hone par us tak pahunche bina hi 403 deta hai.

Ek se zyada chain kab: jab ek hi application stateless JSON API aur browser UI dono deti ho. API wali chain ko securityMatcher("/api/**") dijiye, CSRF band aur token authentication ke saath; doosri chain browser wala hissa sambhale, CSRF ON aur form login ke saath. @Order tay karta hai kaunsi pehle dekhi jaayegi, aur pehla match hi jeetta hai — catch-all chain pehle rakh di to wo har request nigal legi aur specific chain kabhi chalegi hi nahi.

Trade-off kya hai: filter saste hain par muft nahi, aur usse badi baat — wo aapke source me dikhte nahi. Kyunki security dispatcher servlet se pehle chalti hai, security ka failure aapke controller tak pahunchta hi nahi — matlab @ControllerAdvice aur ProblemDetail 401 ya 403 ka roop nahi badalte. Un responses ko apne hisaab se banane ke liye AuthenticationEntryPoint ya AccessDeniedHandler chahiye, jo isi chapter ka aage wala topic hai.

// ---- 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++;
      }
    }
  }
}

Ye chapter ka entry project hai, aur ye jaan-boojh kar koi nayi application nahi hai. Spring Data JPA chapter ne ek job board banaya tha — companies, jobs, paging ke saath search, job band karna — aur uspar koi authentication tha hi nahi. Jo bhi us API tak pahunch sakta tha wo job post kar sakta tha ya kisi aur ki job band kar sakta tha. Ye project uspar taala lagata hai.

Interview bhi isi kram me poochta hai: aapne API banayi, database joda, secure kaise kiya?

Pichhle chapter se ek imaandaar farak

JPA chapter bina web layer ke chala tha; is chapter me web layer hai aur database nahi hai. Isliye yahan entities JPA entities ke bajay ek Map me pade record hain. Security par iska koi asar nahi — filter chain ko pata hi nahi hota ki controller ke peechhe kya hai — par is file ko persistence wale kaam ka vikalp mat samajhiye. Dono halves jaan-boojh kar un chapters me padhaye gaye hain jo unhe sach me chala sakte hain.

Rules, aur har ek ka aakaar aisa kyun hai

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

Matchers method-aware hain. GET /api/jobs aur POST /api/jobs ek hi path hain par do bilkul alag permissions ke saath, jo asli API me aam baat hai — job feed padhna public hai, usme chhapna nahi. Sirf path wala matcher ye keh hi nahi sakta.

Kram specific se general hai. Har rule apne baad wale se sankra hai, aur anyRequest() sabse aakhir me hai. Ulta likhne par application start hi nahi hoti — authorizing-requests wala topic use naapta hai.

Aakhri line ek whitelist hai. anyRequest().authenticated() ka matlab hai ki /api/jobs/mine, jiska kisi rule me zikr tak nahi, anonymous callers ke liye default me band hai. Agle mahine koi /api/jobs/{id}/applicants jodega aur security config bhool jaayega, to wo bhi band hi rahega. authenticated() par khatam karne ka poora tark yahi hai.

csrf.disable() aur STATELESS yahan sahi hain, aur sirf credential ki wajah se: HTTP Basic ek aise header me aata hai jise browser khud kabhi nahi jodta. Credential ko cookie me le jaaiye aur dono faisle galat ho jaate hain.

Run kya sabit karta hai

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

Doosri aur teesri row ko saath padhiye — poora 401-banaam-403 wala sabak usi shakal me hai jisme wo asal me milta hai. Wahi POST, do baar mana, do alag wajahon se: koi nahi ko 401, galat koi ko 403.

Aur paanchvi-chhathi row: wahi endpoint, wahi status, alag data. /api/jobs/mine ko kisi rule ne bachaya hi nahi — use controller bachata hai, Authentication.getName() se filter karke. Ye farak maayne rakhta hai: authorization ke rules tay karte hain ki aap kisi cheez ko bula sakte hain ya nahi; ye ki aapko kaunsi rows dikhengi, wo sirf aapka code tay kar sakta hai. Koi rule kabhi "aapki apni jobs" nahi keh sakta.

Khud banaiye

1. Teen users BCrypt se encode kiye hue passwords ke saath — ek candidate, ek recruiter, ek admin. Demo ke bahar {noop} kabhi nahi.
2. Upar wale chaar rules. Har ek ko do taraf se jaanchiye: wo role jise pass hona chahiye, aur wo jise nahi.
3. GET /api/jobs/mine ko Authentication.getName() se filter kijiye.
4. Phir jaan-boojh kar todiye aur dekhiye: hasRole("RECRUITER") ko hasAuthority("RECRUITER") kar dijiye aur har post 403 se fail hogi, kyunki stored authority ROLE_RECRUITER hai.

Ye dhaancha kab: har us API me jisme reads public hain aur writes adhikaar wale — yaani zyadatar API. Chain par mote rules, code me row-level faisle.

Kab NAHI: ownership ko authorizeHttpRequests me likhne ki koshish mat kijiye. "Jis recruiter ne ye job post ki sirf wahi use band kar sakta hai" URL ka rule hai hi nahi — wo ya to argument ke saath @PreAuthorize hai, ya service me ek check. Matchers ko ownership ke rules me morna aisi configuration banata hai jise koi padh nahi sakta aur aise chhed jo kisi ko dikhte nahi.

Trade-off kya hai: ye rules theek isliye padhne laayak hain kyunki mote hain, aur mote rules us service method ko nahi bacha sakte jo kisi scheduled job ya doosre controller se pahuncha jaaye. Yahi gap agle do projects aur method-security wala topic bharte hain.

// ---- 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());
}