Spring Security AntPathRequestMatcher and permitAll no longer work as expected.

Describe the bug After upgrading to spring-security 6, permitAll configuration does NOT work as expected. When using an AntPathRequestMatcher which only specifies the path, any attempt to access the path where the HttpMethod does not match now responds with 401 Unauthorized instead of the expect 405 Method Not Allowed.

Similarly, access to an unknown sub resource/path now responds with 401 Unauthorized instead of 404 Not Found

The behavior is not consistent either. If you configure any request as permit all then 405 and 404 are returned as expected.

To Reproduce Consider the following test which configures spring-security to permit all requests to /ant-matchers/**, however the methodNotAllowed and notFound tests fail unexpectedly. The sample also includes a test where anyRequest().permitAll() is used and the test cases pass as expected as they did prior to 6.x

@SpringBootTest(classes = TestApplication.class, webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
class AntMatcherPermitAllTest {

  @Resource
  private TestRestTemplate restTemplate;

  @Test
  void methodNotAllowed() {
    assertThat(restTemplate
        .postForEntity("/ant-matchers/test", null, Void.class))
        .hasFieldOrPropertyWithValue("statusCode", HttpStatus.METHOD_NOT_ALLOWED);
  }

  @Test
  void noContent() {
    assertThat(restTemplate
        .getForEntity("/ant-matchers/test", null, Void.class))
        .hasFieldOrPropertyWithValue("statusCode", HttpStatus.NO_CONTENT);
  }

  @Test
  void notFound() {
    assertThat(restTemplate
        .getForEntity("/any-request/unknown-endpoint", null, Void.class))
        .hasFieldOrPropertyWithValue("statusCode", HttpStatus.NOT_FOUND);
  }

  @SpringBootApplication(proxyBeanMethods = false)
  @RestController
  static class TestApplication {

    @GetMapping("/ant-matchers/test")
    @ResponseStatus(HttpStatus.NO_CONTENT)
    void test() {
    }

    @Bean
    public SecurityFilterChain basicWebSecurityFilterChain(HttpSecurity http) throws Exception {
      return http
          .authorizeHttpRequests(
              auth -> auth.requestMatchers(AntPathRequestMatcher.antMatcher("/ant-matchers/**"))
                  .permitAll())
          .httpBasic(basic -> basic.realmName("test"))
          .csrf(CsrfConfigurer::disable)
          .sessionManagement(sessionConfigurer -> sessionConfigurer
              .sessionCreationPolicy(SessionCreationPolicy.STATELESS)
          )
          .build();
    }
  }
}

Expected behavior When the HTTP Method does not match 405 Method Not Allowed should be returned When attempting to access an unknown path 404 Not Found should be returned.

Sample https://github.com/kelseyh/permit-all-bug

Comment From: jzheaux

HI, @kelseyh, thanks for reaching out. I downloaded your sample and ran the tests. Here are a few observations:

First, /error from Spring Boot is no longer permitAll by default. The reason that you get a 401 instead of 405 is because /error is not permitted. Once I add .requestMatchers("/error").permitAll(), then the 405 is returned as expected.

Second, the 404 test uses /any-request/unknown-endpoint instead of /ant-matchers/unknown-endpoint. Once I changed that (and left /error permitted), then the 404 is returned as expected.

Third, if /any-request/unknown-endpoint is not a typo, then this behaves as expected as well: All endpoints by default require authentication. This behavior was changed from 5.8 to 6.0 to deny any unspecified request by default.

As far as I can tell, the above answers your questions. Is there anything else that you feel is still in error?

Comment From: kelseyh

Hi Firstly, apologies for the copy/paste error.

Thank you for pointing out the change to /error no longer being permittAll. This explains why anyRequest().permitAll() and antMatcher("/**") work.

Does that make sense though? Surely errors should be surfaced by default rather than hiding them with a 401. It would be good to understand the design decision around that.

Thanks again.

Comment From: jzheaux

Does that make sense though?

Good question. I like @rwinch's explanation.