WebSecurity.ignoring().anyRequest() no longer works

[crmky]

Describe the bug

In Spring Security 6.3.x, we can use WebSecurityCustomizer to customize WebSecurity to ignore all security checks. This is not for production, but useful for local testing when some properties are set. A simplified version:

@Configuration(proxyBeanMethods = false)
public class ApplicationConfiguration {

    @Bean
    WebSecurityCustomizer ignoreAllCustomizer() {
        return web -> web.ignoring().anyRequest();
    }
}

However because of #15220 and #15982, ignore all requests doesn't work anymore. Below exception will be thrown:

Caused by: org.springframework.security.web.UnreachableFilterChainException: A filter chain that matches any request [DefaultSecurityFilterChain matching [any request] and having filters []] has already been configured, which means that this filter chain [DefaultSecurityFilterChain defined as 'managementSecurityFilterChain' in [class path resource [org/springframework/boot/actuate/autoconfigure/security/servlet/ManagementWebSecurityAutoConfiguration.class]] matching [any request] and having filters [DisableEncodeUrl, WebAsyncManagerIntegration, SecurityContextHolder, HeaderWriter, Cors, Csrf, Logout, UsernamePasswordAuthentication, DefaultResources, DefaultLoginPageGenerating, DefaultLogoutPageGenerating, BasicAuthentication, RequestCacheAware, SecurityContextHolderAwareRequest, AnonymousAuthentication, ExceptionTranslation, Authorization]] will never get invoked. Please use `HttpSecurity#securityMatcher` to ensure that there is only one filter chain configured for 'any request' and that the 'any request' filter chain is published last.

The cause of this issue is WebSecurityFilterChainValidator now validate WebSecurity ignoredRequests together with HttpSecurity filter chain together. It will throw the above exception in that case.

To Reproduce

Create a Configuration class like the one mentioned above.

Expected behavior

I think WebSecurity.ignoring().anyRequest() should still get supported. I understand this is not for the production, but it provides a way to skip all the customizations in HttpSecurity.

[jzheaux]

Thanks for the report, @crmky! @franticticktick is this something you would be able to help with?

[franticticktick]

@jzheaux yes, sure. @crmky could you please provide a minimal reproducible sample?

[crmky]

@franticticktick You can create a minimal Spring Boot application using Spring initializer: https://start.spring.io/#!type=maven-project&language=java&platformVersion=3.5.0-RC1&packaging=jar&jvmVersion=17&groupId=com.example&artifactId=demo&name=demo&description=Demo%20project%20for%20Spring%20Boot&packageName=com.example.demo&dependencies=security,web

Then copy the previously mentioned ApplicationConfiguration class to the project source folder to reproduce the issue.

[franticticktick]

hi @crmky, actually this is expected behavior, we have two DefaultSecurityFilterChain - one from spring boot, the second one is yours from ignoreAllCustomizer. Yes, they are different from each other, but even though you use such configuration in test environment, it can lead to security breaches of your API, we can't guarantee that such trick won't be used in production.

Maybe you should consider other solutions for solving your problem? If you give more details, we can help you.

[crmky]

However this is a significantly behavior change after upgrade from Spring Boot 3.3 to 3.5. Those logic used to work well in Spring Boot 3.3 (with Spring Security 6.3) and now breaks in Spring Boot 3.5 (with Spring Security 6.5).

Our use case is to skip all security customization (typically for HttpSecurity) conditionally, e.g. when a property is set. This is typically used in local development environment where developers wants to focus on the business logic instead of security.

[franticticktick]

I understand you. For a long time, this was a bug - chain validation was not performed correctly. Naturally, many developers started to use this bug as a feature. However, I believe that the current behavior is exactly as it should be.

WebSecurity.ignoring().anyRequest() can create a dangerous precedent - when any chain can be cancelled using ignoring(). There are other ways to solve your problem: for example, you can create another profile (local or test) with your own configuration (TestSecurityConfig), in which to provide permitAll for all requests. In fact, there are many solutions.

[crmky]

The challenge for HttpSecurity.authorizeHttpRequests() is once anyRequest() is configured, it throw exception for any additional customization. Make things worse, it doesn't expose any method to let external callers aware of anyRequest() is configured or not.

That means once we inject below code:

http.authorizeHttpRequests(requests -> requests.anyRequest().permitAll());

Any other customization to HttpSecurity needs to aware of that and stop perform additional authorization settings. This is not always possible.

Anyway if you think that's the desired behavior, I can always find ways to workaround.

[franticticktick]

The challenge for HttpSecurity.authorizeHttpRequests() is once anyRequest() is configured, it throw exception for any additional customization. Make things worse, it doesn't expose any method to let external callers aware of anyRequest() is configured or not.

Could you please explain the problem in more detail? In addition, the securityMatcher functionality may help in your case. I don't remember exactly if we have sample for your case, if not, we can add it. There will be sample of how to solve your problem without WebSecurity.ignoring().anyRequest().