Bird
Raised Fist0
Spring Bootframework~10 mins

SecurityFilterChain configuration in Spring Boot - Step-by-Step Execution

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Concept Flow - SecurityFilterChain configuration
Start Application
Create SecurityFilterChain Bean
Configure HttpSecurity
Build Filter Chain
Apply Filters on Requests
Authorize or Deny Access
End
The application starts, creates a SecurityFilterChain bean, configures HTTP security rules, builds the filter chain, applies filters on incoming requests, and then authorizes or denies access.
Execution Sample
Spring Boot
  @Bean
  public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    http.authorizeHttpRequests(auth -> auth
      .requestMatchers("/public/**").permitAll()
      .anyRequest().authenticated()
    ).formLogin();
    return http.build();
  }
Defines a security filter chain that allows public access to '/public/**' URLs and requires authentication for others, enabling form login.
Execution Table
StepActionHttpSecurity StateFilterChain StateResult
1Start application and call filterChain beanEmpty configurationNo filters builtPreparing to configure security
2Configure authorizeHttpRequestsRules: '/public/**' permitAll, others authenticatedNo filters builtAuthorization rules set
3Enable formLoginForm login enabledNo filters builtLogin page configured
4Build filter chainConfiguration lockedFilter chain created with filters for auth and loginFilter chain ready
5Incoming request to '/public/home'Rules appliedFilter chain processes requestAccess granted without login
6Incoming request to '/user/profile'Rules appliedFilter chain processes requestAccess requires authentication
7User submits login formForm login processingFilter chain processes loginUser authenticated
8Access '/user/profile' after loginRules appliedFilter chain processes requestAccess granted
9End of flowStable security stateFilter chain activeSecurity enforced on requests
💡 SecurityFilterChain built and applied; requests authorized or denied based on rules.
Variable Tracker
VariableStartAfter Step 2After Step 3After Step 4After Step 9
http.authorizeHttpRequests.rulesempty'/public/**' permitAll, others authenticated'/public/**' permitAll, others authenticated'/public/**' permitAll, others authenticated'/public/**' permitAll, others authenticated
http.formLogin.enabledfalsefalsetruetruetrue
filterChain.builtfalsefalsefalsetruetrue
Key Moments - 3 Insights
Why does '/public/home' not require login while '/user/profile' does?
Because the authorizeHttpRequests rule explicitly permits all access to '/public/**' paths (see execution_table step 5), while all other requests require authentication (step 6).
What happens if we forget to call http.build()?
The filter chain is not created or applied, so no security filters run on requests. This is shown in execution_table step 4 where building the chain finalizes configuration.
How does formLogin() affect the filter chain?
Enabling formLogin adds filters to handle login forms and authentication (step 3 and 4). Without it, login pages and processing are not set up.
Visual Quiz - 3 Questions
Test your understanding
Look at the execution_table, what is the state of http.formLogin.enabled after step 3?
Atrue
Bfalse
Cnull
Dundefined
💡 Hint
Check the 'HttpSecurity State' column at step 3 in execution_table.
At which step does the filter chain get created and ready to use?
AStep 2
BStep 6
CStep 4
DStep 1
💡 Hint
Look for 'Filter chain created' in the 'FilterChain State' column.
If we remove the permitAll rule for '/public/**', what will happen at step 5?
AAccess denied for all requests
BAccess requires authentication
CAccess granted without login
DApplication crashes
💡 Hint
Refer to the authorization rules in variable_tracker and execution_table step 5.
Concept Snapshot
SecurityFilterChain configuration:
- Define a @Bean method returning SecurityFilterChain
- Use HttpSecurity to set rules (authorizeHttpRequests)
- Permit or require authentication per URL pattern
- Enable login methods (formLogin, etc.)
- Call http.build() to create the chain
- Spring applies filters to incoming requests enforcing rules
Full Transcript
This visual execution trace shows how Spring Boot creates and applies a SecurityFilterChain. The application starts and calls a bean method that configures HttpSecurity. Authorization rules are set to allow public access to '/public/**' and require authentication for others. Form login is enabled to handle user authentication. The filter chain is built and then applied to incoming requests. Requests to public URLs pass without login, while others require authentication. After login, access is granted. Variables track the state of rules and filter chain creation. Key moments clarify why some URLs are public and the importance of building the chain. Quiz questions test understanding of configuration steps and effects.

Practice

(1/5)
1. What is the primary purpose of a SecurityFilterChain in Spring Boot?
easy
A. To handle file uploads
B. To define security rules for web requests and control access
C. To manage application logging levels
D. To configure database connections

Solution

  1. Step 1: Understand the role of SecurityFilterChain

    The SecurityFilterChain is used in Spring Security to define how HTTP requests are secured, including which URLs require authentication and what roles can access them.
  2. Step 2: Compare with other options

    Database connections, logging, and file uploads are unrelated to SecurityFilterChain's purpose.
  3. Final Answer:

    To define security rules for web requests and control access -> Option B
  4. Quick Check:

    SecurityFilterChain controls web security = D [OK]
Hint: SecurityFilterChain controls web request security rules [OK]
Common Mistakes:
  • Confusing SecurityFilterChain with database or logging config
  • Thinking it manages file uploads
  • Assuming it handles application-wide settings
2. Which of the following is the correct way to declare a SecurityFilterChain bean in Spring Boot?
easy
A. @Component public void filterChain(HttpSecurity http) { http.build(); }
B. public SecurityFilterChain filterChain() { return new SecurityFilterChain(); }
C. @Bean public void filterChain() { return http.build(); }
D. @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { return http.build(); }

Solution

  1. Step 1: Identify correct bean declaration syntax

    In Spring Boot, a SecurityFilterChain bean must be annotated with @Bean, accept HttpSecurity as a parameter, and return the built chain with http.build().
  2. Step 2: Check each option

    @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { return http.build(); } correctly uses @Bean, returns SecurityFilterChain, and calls http.build(). Options B and D have wrong return types or missing annotations. @Component public void filterChain(HttpSecurity http) { http.build(); } uses @Component and void return, which is incorrect.
  3. Final Answer:

    @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { return http.build(); } -> Option D
  4. Quick Check:

    Correct bean method signature = C [OK]
Hint: Bean method must return SecurityFilterChain and use @Bean [OK]
Common Mistakes:
  • Forgetting @Bean annotation
  • Using void return type
  • Not passing HttpSecurity parameter
3. Given this SecurityFilterChain configuration snippet, what will happen when a user accesses /admin URL?
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
  http.authorizeHttpRequests(auth -> auth
    .requestMatchers("/admin").hasRole("ADMIN")
    .anyRequest().authenticated()
  ).formLogin();
  return http.build();
}
medium
A. All URLs are open without authentication
B. Anyone can access /admin without login
C. Only users with role ADMIN can access /admin; others must log in
D. Access to /admin is denied to everyone

Solution

  1. Step 1: Analyze the authorization rules

    The config states that requests to "/admin" require the user to have role "ADMIN". All other requests require authentication but no specific role.
  2. Step 2: Understand formLogin and access control

    Form login is enabled, so users must log in. Only users with ADMIN role can access /admin; others will be blocked or redirected to login.
  3. Final Answer:

    Only users with role ADMIN can access /admin; others must log in -> Option C
  4. Quick Check:

    /admin requires ADMIN role = A [OK]
Hint: Check requestMatchers roles and formLogin presence [OK]
Common Mistakes:
  • Assuming /admin is open to all
  • Ignoring role restrictions
  • Thinking formLogin disables security
4. Identify the error in this SecurityFilterChain configuration:
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) {
  http.authorizeHttpRequests(auth -> auth
    .requestMatchers("/user").authenticated()
    .anyRequest().permitAll()
  );
  return http.build();
}
medium
A. Missing throws Exception in method signature
B. Calling http.build() without returning it
C. No error, configuration is correct
D. Using permitAll() before authenticated() causes error

Solution

  1. Step 1: Check method signature for exceptions

    The http.build() method can throw a checked exception, so the method should declare throws Exception.
  2. Step 2: Verify return statement and method correctness

    The method returns http.build() correctly. The order of authenticated() and permitAll() is valid. So the only issue is missing exception declaration.
  3. Final Answer:

    Missing throws Exception in method signature -> Option A
  4. Quick Check:

    http.build() may throw Exception = B [OK]
Hint: Add throws Exception when calling http.build() [OK]
Common Mistakes:
  • Omitting throws Exception causes compile error
  • Misunderstanding order of permitAll and authenticated
  • Forgetting to return http.build()
5. You want to configure a SecurityFilterChain that allows anonymous access to /public/**, requires authentication for /user/**, and restricts /admin/** to users with role ADMIN, and denies access to all other requests. Which configuration snippet correctly implements this?
hard
A. @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http.authorizeHttpRequests(auth -> auth .requestMatchers("/public/**").permitAll() .requestMatchers("/user/**").authenticated() .requestMatchers("/admin/**").hasRole("ADMIN") .anyRequest().denyAll() ).formLogin(); return http.build(); }
B. @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http.authorizeHttpRequests(auth -> auth .requestMatchers("/admin/**").hasRole("ADMIN") .requestMatchers("/user/**").authenticated() .requestMatchers("/public/**").permitAll() .anyRequest().authenticated() ).formLogin(); return http.build(); }
C. @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http.authorizeHttpRequests(auth -> auth .requestMatchers("/public/**").authenticated() .requestMatchers("/user/**").permitAll() .requestMatchers("/admin/**").hasRole("ADMIN") .anyRequest().denyAll() ).formLogin(); return http.build(); }
D. @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http.authorizeHttpRequests(auth -> auth .requestMatchers("/public/**").permitAll() .requestMatchers("/user/**").permitAll() .requestMatchers("/admin/**").authenticated() .anyRequest().denyAll() ).formLogin(); return http.build(); }

Solution

  1. Step 1: Match access rules to URL patterns

    The requirement is: /public/** open to all (permitAll), /user/** requires authentication, /admin/** requires ADMIN role, and all others denied.
  2. Step 2: Check each option's order and rules

    @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http.authorizeHttpRequests(auth -> auth .requestMatchers("/public/**").permitAll() .requestMatchers("/user/**").authenticated() .requestMatchers("/admin/**").hasRole("ADMIN") .anyRequest().denyAll() ).formLogin(); return http.build(); } matches the requirements exactly. @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http.authorizeHttpRequests(auth -> auth .requestMatchers("/admin/**").hasRole("ADMIN") .requestMatchers("/user/**").authenticated() .requestMatchers("/public/**").permitAll() .anyRequest().authenticated() ).formLogin(); return http.build(); } allows anyRequest authenticated (not denyAll). @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http.authorizeHttpRequests(auth -> auth .requestMatchers("/public/**").authenticated() .requestMatchers("/user/**").permitAll() .requestMatchers("/admin/**").hasRole("ADMIN") .anyRequest().denyAll() ).formLogin(); return http.build(); } swaps permitAll and authenticated for /public and /user incorrectly. @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http.authorizeHttpRequests(auth -> auth .requestMatchers("/public/**").permitAll() .requestMatchers("/user/**").permitAll() .requestMatchers("/admin/**").authenticated() .anyRequest().denyAll() ).formLogin(); return http.build(); } permits /user/** to all and only authenticates /admin/**, which is wrong.
  3. Final Answer:

    @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http.authorizeHttpRequests(auth -> auth .requestMatchers("/public/**").permitAll() .requestMatchers("/user/**").authenticated() .requestMatchers("/admin/**").hasRole("ADMIN") .anyRequest().denyAll() ).formLogin(); return http.build(); } -> Option A
  4. Quick Check:

    Correct URL access rules = A [OK]
Hint: Match URL patterns to correct access methods in order [OK]
Common Mistakes:
  • Mixing permitAll and authenticated for URLs
  • Forgetting to restrict admin URLs by role
  • Using anyRequest().authenticated() instead of denyAll()