Security Config

1. SecurityConfig: Architecting the Security Posture

Think of this class as the authoritative blueprint for your application’s security. It doesn’t just enable security; it dictates the precise rules of engagement for every single request that enters your service. In an interview, demonstrating a command of this file proves you understand security architecture, not just code.

1.1. Core Philosophy: @EnableWebSecurity and @EnableMethodSecurity

These annotations are the foundational switches that activate Spring Security’s powerful machinery.

• @EnableWebSecurity: This is the master switch. It imports a comprehensive set of security configurations and ensures that the core Spring Security filter chain is registered and applied to all incoming web requests. Without this, your SecurityFilterChain bean would be ignored entirely. It signals to Spring Boot’s auto-configuration that this is the primary source of web security rules.

• @EnableMethodSecurity: This annotation activates a more granular, powerful layer of security that operates at the method level, not just the URL level. While your current SecurityConfig focuses on URL-based authorization (authorizeHttpRequests), @EnableMethodSecurity allows you to secure individual service or controller methods directly.

  • Example Use Case:

    @Service
    public class PatientService {
        @PreAuthorize("hasRole('ADMIN') or #username == authentication.principal.username")
        public PatientRecord getPatientRecord(String username) {
            // ... logic
        }
    }

  • Interview Insight: This demonstrates the principle of Defense in Depth. You establish broad security rules at the URL level (macro-control) and then apply fine-grained, business-specific rules at the method level (micro-control). Mentioning this distinction shows a mature understanding of security design.

1.2. The Filter Chain Explained: Deconstructing Your SecurityFilterChain

A common interview question involves whiteboarding the flow of an HTTP request through Spring Security. The SecurityFilterChain is the definition of that flow. It is an ordered chain of filters, where each filter has a specific responsibility.

Here is a simplified visualization of your configured chain:

Client Request
      |
      V
[ CorsFilter ] <--- Manages cross-origin browser requests (enabled by .cors())
      |
      V
[ CsrfFilter (Disabled) ] <--- Skipped because of .csrf(AbstractHttpConfigurer::disable)
      |
      V
[ HeaderWriterFilter ] <--- Adds security headers (enabled by .headers())
      |
      V
[ AuthTokenFilter ] <--- YOUR CUSTOM FILTER: Parses and validates the JWT
      |
      V
[ UsernamePasswordAuthenticationFilter ] <--- (Effectively bypassed for JWT requests)
      |
      V
[ AuthorizationFilter ] <--- Enforces the rules defined in .authorizeHttpRequests()
      |
      V
[ Controller Endpoint ]

• API Security Tenets: csrf(disable) and cors()

  • csrf(AbstractHttpConfigurer::disable): CSRF (Cross-Site Request Forgery) is an attack where a malicious site tricks a user’s browser into making an unintended request to your application where the user is already authenticated (e.g., via a session cookie).

    • Why is it disabled? In a pure stateless JWT architecture, the server does not rely on session cookies that browsers automatically attach to requests. The JWT is manually attached to the Authorization header by the client-side code. Since there is no session to exploit, traditional CSRF attacks are not a risk. Disabling it removes unnecessary overhead.
    • Interview Caution: Be prepared to state the exception. If you were to store the JWT in a cookie (not recommended for security reasons), you would absolutely need to re-enable and configure CSRF protection.

  • cors(cors -> cors.configurationSource(corsConfigurationSource())): CORS (Cross-Origin Resource Sharing) is a browser security mechanism that restricts a web page from making API calls to a different domain, protocol, or port than the one it came from.

    • Why is it essential? Your configuration explicitly defines a CorsConfigurationSource bean. This tells the browser which external domains (e.g., http://localhost:3000 for a React frontend) are permitted to access your API. Without this, a modern browser would block your frontend application from fetching data, citing a CORS policy violation. This is not server-side security; it’s a server-enforced rule for browser-based clients.

• Statelessness as a Principle: sessionManagement(sess -> sess.sessionCreationPolicy(SessionCreationPolicy.STATELESS))

  • This is the single most important line of code for defining a JWT-based security model.
  • What it does: It instructs Spring Security to never create or use an HttpSession. Each request must be treated as a completely independent transaction, with no memory of previous requests.
  • Why it’s critical for JWT: The core benefit of JWT is statelessness. All the information required to process the request (i.e., the user’s identity and permissions) is contained within the token itself. This allows for horizontal scalability, as any instance of your service can authenticate the request without needing to access a shared session store.

• Authorization Strategy: authorizeHttpRequests(...)

  • This block enforces access rules based on request paths. The rules are evaluated in order.
  • .requestMatchers("/api/auth/**", "/v3/api-docs/**", ...).permitAll(): This “whitelists” specific endpoints. It’s crucial for paths required before a user is authenticated, such as login, registration, and API documentation.
  • .anyRequest().authenticated(): This is a critical security best practice known as fail-safe default. It declares that any request that has not been explicitly matched by a preceding rule must be authenticated. This prevents accidental exposure of new endpoints.

1.3. Password Integrity: The PasswordEncoder

• Role: The PasswordEncoder bean, specifically BCryptPasswordEncoder, is responsible for applying a strong, one-way cryptographic hash to user passwords before they are stored. The principle is simple: never store plain-text passwords.
• Why Bcrypt is a strong default:
  1. Adaptive Hashing: Bcrypt has a configurable “work factor” that can be increased over time as computing power grows, making it more resistant to brute-force attacks.
  2. Automatic Salting: It automatically generates and incorporates a random salt with each password hash. This ensures that two identical passwords will result in completely different hashes, rendering pre-computed hash lists (rainbow tables) useless.

1.4. Interview Focus: Synthesizing the Knowledge

Question: “Walk me through your SecurityConfig and explain why this specific configuration is necessary for a secure, stateless, JWT-based REST API.”

Your Answer: “Our SecurityConfig establishes a stateless security posture, which is ideal for scalable web services.

1. We begin by disabling CSRF because our API is stateless and uses bearer tokens in the Authorization header, not session cookies, which mitigates traditional CSRF risks. We enable and meticulously configure CORS to allow our designated frontend applications to interact with the API securely from a browser.

2. The most critical declaration is setting the sessionCreationPolicy to STATELESS. This forces every request to be independently authenticated via its JWT, which is the cornerstone of our architecture. It guarantees that the server does not maintain session state.

3. We define our authorization rules with a ‘deny-by-default’ strategy. We explicitly permitAll for public endpoints like authentication and API docs, and then enforce that anyRequest must be authenticated.

4. Finally, we insert our custom AuthTokenFilter before the standard UsernamePasswordAuthenticationFilter. This custom filter is responsible for intercepting every request, validating the JWT from the header, and populating the SecurityContext. This effectively makes our JWT validation the primary authentication mechanism for the application.”