Spring Security 5.7: What's New, Release History & EOL Status

What Is New in Spring Security 5.7

Can @EnableMethodSecurity now secure methods declared on interfaces?

Yes - the proxy-based method security now correctly resolves security annotations placed on interface methods.

• Prior to 5.7, annotations on an interface were ignored when the bean was proxied, leading to unsecured calls.
• In practice, this means you can keep your service contracts clean (e.g., public interface OrderService { @PreAuthorize("hasRole('ADMIN')") void cancel(Long id); }) without adding duplicate annotations on the implementation.
• Migration tip: no code change is required; just upgrade and run your existing tests to confirm the security checks fire.

How does Spring Security 5.7 improve reactive session handling?

Spring Security 5.7 adds a Mono.cache option to WebSessionServerSecurityContextRepository for efficient reuse of the security context.

@Bean
public ServerSecurityContextRepository securityContextRepository() {
    return new WebSessionServerSecurityContextRepository()
            .setCacheMono(true); // enables Mono.cache()
}

• This reduces repeated lookups of the security context during a single request lifecycle.
• Most teams will see lower latency in high-throughput WebFlux applications.
• Watch out for memory pressure if you enable caching for long-lived sessions; configure a reasonable timeout.

What enhancements were made to remember-me and X509 authentication?

Both mechanisms now automatically detect a UserDetailsService bean, removing the need for explicit configuration.

• Previously you had to wire RememberMeServices or X509AuthenticationProvider with a reference to your UserDetailsService.
• In production this simplifies security configuration files and reduces boilerplate.
• Example (remember-me): http.rememberMe() will now pick up the existing UserDetailsService bean automatically.

How was AuthorityAuthorizationManager optimized for large authority sets?

AuthorityAuthorizationManager now uses a Set<String> of authority strings instead of iterating an inner loop.

• This change dramatically improves performance when evaluating permissions against users with many roles.
• In practice, you'll notice faster authorization decisions in micro-service environments where JWTs contain dozens of scopes.
• No API change; existing code that calls .hasAuthority(...) continues to work.

Why do multiple .requestMatchers().mvcMatchers() no longer override each other?

Spring Security 5.7 fixes the matcher ordering bug so that each matcher is evaluated in the order it is declared.

http
    .authorizeHttpRequests(authorize -> authorize
        .requestMatchers("/admin/**").hasRole("ADMIN")
        .mvcMatchers("/admin/reports/**").hasAuthority("REPORT_VIEW")
        .anyRequest().authenticated());

• Before this release, the later mvcMatchers could unintentionally replace earlier requestMatchers, causing security gaps.
• Now you can safely combine different matcher types without worrying about hidden overrides.
• Most teams will only need to run their integration tests to verify the intended access rules.