Upgrading to Spring Security 6.0: Replacing Removed and Deprecated Request Security Functionality

Overview of API Changes in Spring Security 6.0

With the release of Spring Boot 3.0.0 and Spring Security 6.0, the security configuration API has undergone significant refactoring. These changes aim to simplify the configuration process and improve API consistency. During the upgrade process, developers need to pay special attention to several key changes: the authorizeRequests() method has been deprecated, the antMatchers(), mvcMatchers(), and regexMatchers() methods have been removed from the API, and the @EnableGlobalMethodSecurity annotation has been replaced with new alternatives.

Migration Strategy for Request Security Configuration

In Spring Security 6.0, the core changes in request security configuration manifest at two levels: method-level replacements and unified configuration approaches.

From authorizeRequests() to authorizeHttpRequests()

The authorizeRequests() method has been marked as deprecated in Spring Security 6.0, with the new authorizeHttpRequests() method recommended as its replacement. This change is not merely a renaming but reflects the Spring Security team's redesign of HTTP request authorization configuration. The new method provides clearer semantics, explicitly distinguishing authorization handling for HTTP requests.

Unified Request Matcher: requestMatchers()

Spring Security 6.0 removes the scattered matcher methods such as antMatchers(), mvcMatchers(), and regexMatchers(), introducing the unified requestMatchers() method. This method supports various matching patterns through overloaded versions, including Ant-style paths, MVC pattern matching, and regular expression matching. This design simplifies the API and reduces the learning curve for developers.

Code Migration Example

The following is a specific migration example demonstrating how to convert legacy security configuration to Spring Security 6.0 compatible format:

@Bean
public SecurityFilterChain filterChain(HttpSecurity httpSecurity) throws Exception {
    return httpSecurity
        .csrf(csrf -> csrf.disable())
        .authorizeHttpRequests(auth -> auth
            .requestMatchers("/token/**").permitAll()
            .anyRequest().authenticated()
        )
        .sessionManagement(sess -> sess.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
        .oauth2ResourceServer(OAuth2ResourceServerConfigurer::jwt)
        .httpBasic(Customizer.withDefaults())
        .build();
}

In this example, we can observe several key changes:

1. authorizeRequests() is replaced with authorizeHttpRequests()
2. antMatchers("/token/**") is replaced with requestMatchers("/token/**")
3. The configuration structure is more compact, with multiple authorization rules definable within a single authorizeHttpRequests() call

Updates to Method-Level Security Configuration

Beyond request-level security configuration, the approach to enabling method-level security annotations has also changed. The @EnableGlobalMethodSecurity annotation has been replaced by @EnableMethodSecurity. The new annotation enables the prePostEnabled feature by default, meaning developers no longer need to explicitly set prePostEnabled = true.

Simplification of Configuration Class Annotations

In Spring Security 6.0, configuration classes can be simplified to:

@Configuration
@EnableWebSecurity
@EnableMethodSecurity
public class SecurityConfig {
    // Configuration content
}

This simplification reduces boilerplate code and makes configurations more intuitive. It's important to note that @EnableMethodSecurity by default supports @PreAuthorize, @PostAuthorize, @PreFilter, and @PostFilter annotations, which aligns with the behavior of the legacy @EnableGlobalMethodSecurity(prePostEnabled = true).

Migration Considerations

When migrating to Spring Security 6.0, developers should consider the following points:

API Compatibility Checking

It is recommended to thoroughly check all Spring Security API calls used in the project before migration. Beyond the major changes mentioned in this article, there may be other subtle API adjustments. Using IDE code analysis tools can help identify incompatible API usage.

Test Coverage

Changes to security configuration may affect application access control logic. After migration, ensure adequate test coverage, particularly for tests targeting different user roles and permission paths. Creating dedicated integration tests to verify the correctness of security configurations is advisable.

Incremental Migration

For large projects, consider adopting an incremental migration strategy. New security configurations can be applied in specific modules first, gradually replacing legacy configuration approaches. This strategy reduces migration risks and provides more time to adapt to the new API design.

Design Philosophy of the New API

The API refactoring in Spring Security 6.0 reflects several important design principles:

Consistency Principle

By unifying the requestMatchers() method, Spring Security provides a more consistent API experience. Developers no longer need to choose different methods based on varying matching requirements, reducing API complexity.

Improved Clarity

The authorizeHttpRequests() method name more clearly expresses its function—authorizing HTTP requests. This naming improvement enhances code readability and maintainability.

Optimized Default Configuration

The default behavior optimization of the @EnableMethodSecurity annotation reduces configuration redundancy. The Spring Security team has made configurations for common use cases more concise through reasonable default value settings.

Conclusion

While the API changes in Spring Security 6.0 require some migration effort, these changes bring a more concise, consistent, and clear security configuration experience. By adopting new APIs such as authorizeHttpRequests() and requestMatchers(), developers can build security configurations that are easier to maintain. Simultaneously, the simplification of the @EnableMethodSecurity annotation further reduces configuration complexity. It is recommended that developers carefully review official documentation during the upgrade process and fully utilize IDE tools to assist with migration work.