Spring Security：直接在HttpSecurity对象上调用antMatcher()而不使用authorizeRequests()的作用及configure方法配置疑问

Great question—let’s break down exactly what’s happening when you call antMatcher() directly on HttpSecurity, and what occurs when you use it without pairing it with authorizeRequests().

1. What does antMatcher() on HttpSecurity do? #

When you call antMatcher() directly on the HttpSecurity object, you’re setting the scope for your entire security configuration. Every subsequent rule you add (like authentication flows, authorization rules, filter setups, etc.) will only apply to requests that match the pattern you specify in antMatcher().

This is distinct from the antMatchers() method inside authorizeRequests()—that one is used to define granular authorization rules for specific paths within the already-scoped configuration.

For example:

@Override
protected void configure(HttpSecurity http) throws Exception {
    // This entire config only applies to requests starting with /api/
    http.antMatcher("/api/**")
        .authorizeRequests()
            .antMatchers("/api/public/**").permitAll() // Allow unauthenticated access to public API paths
            .anyRequest().authenticated() // Require auth for all other API paths
        .and()
        .formLogin() // Custom login setup exclusive to API paths
            .loginPage("/api/login");
}

Here, the login page setup and authorization rules won’t touch paths like /home or /about—they only apply to /api/** routes.

2. What happens if you use antMatcher() without authorizeRequests()? #

If you only call antMatcher() on HttpSecurity and skip authorizeRequests(), here’s the behavior you’ll see:

• For paths matching the antMatcher() pattern: Spring Security falls back to its default authorization rule—all requests require authentication. Users will be redirected to the default Spring Security login page (unless you’ve customized authentication) to access these paths.
• For paths not matching the antMatcher() pattern: This HttpSecurity configuration won’t apply at all. If there are no other security configurations (like additional SecurityFilterChain beans), these paths are completely unprotected—anyone can access them without authentication.

Example of this scenario:

@Override
protected void configure(HttpSecurity http) throws Exception {
    // Only /api/** paths are covered by this config
    http.antMatcher("/api/**");
}

• Requests to /api/users will require authentication (default behavior).
• Requests to /home or /contact aren’t covered by this config, so they’re accessible to everyone.

Key Takeaway #

Think of HttpSecurity.antMatcher() as a "gatekeeper" for your security rules—it narrows down which requests the rest of your configuration applies to. authorizeRequests() is where you define how those requests are authorized (who can access what). Using one without the other isn’t incorrect, but it’s critical to understand the default behavior that kicks in when you skip explicit authorization rules.

内容的提问来源于stack exchange，提问作者user15599360