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

What Is New in Spring Security 6.0

How does Spring Security 6.0 handle servlet and Jakarta namespace changes?

Spring Security 6.0 aligns itself with Servlet API 6 and the Jakarta EE 9+ namespace, which means every javax.* import must be migrated to jakarta.*.

• All internal filters now implement jakarta.servlet.Filter instead of javax.servlet.Filter.
• Support for Jakarta WebSocket 2.1 has been added, enabling secure WebSocket endpoints under the new namespace.
• Configuration classes that extend WebSecurityConfigurerAdapter still compile, but the underlying servlet types have changed.

In practice you will need to update your imports and any custom servlet-based beans. For example:

import jakarta.servlet.Filter;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;

Most IDEs can refactor the package change automatically, but verify that any third-party libraries you use have also migrated to Jakarta.

What are the breaking changes around FilterChainProxy registration?

FilterChainProxy is now registered for all dispatcher types (REQUEST, FORWARD, INCLUDE, ERROR, ASYNC) by default.

• This eliminates the need for manual DispatcherType configuration in FilterRegistrationBean.
• If you previously limited the proxy to DispatcherType.REQUEST, you must review any custom filters that rely on that restriction.
• The change is documented in the migration steps "Register FilterChainProxy for All Dispatcher Types".

Typical migration code:

FilterRegistrationBean<FilterChainProxy> registration = new FilterRegistrationBean<>(filterChainProxy);
registration.setDispatcherTypes(DispatcherType.REQUEST, DispatcherType.FORWARD, DispatcherType.INCLUDE, DispatcherType.ERROR, DispatcherType.ASYNC);

Most teams can simply remove the explicit setDispatcherTypes call and rely on the new default.

What improvements were made to CSRF handling in Spring Security 6.0?

CSRF handling has been tightened: CsrfAuthenticationStrategy now checks for an existing token and is fully consistent with CsrfFilter.

• The strategy no longer creates a duplicate token when one is already present, preventing unnecessary session state.
• Logging has been added to warn when the token is missing or mismatched, aiding debugging.
• These changes fix issue #12241 and bring the CSRF flow in line with the Servlet 6 security contract.

In practice, if you custom-implemented CsrfAuthenticationStrategy, verify that you are not manually generating a token before the filter runs.

Which observability and metric naming updates are included in Spring Security 6.0?

Span and meter names have been polished to follow the OpenTelemetry semantic conventions.

• Micrometer Observation has been upgraded to 1.10.1, providing richer context for security events.
• Instrumentation names now use lower-case, dot-separated format (e.g., spring.security.authentication.success).
• These changes improve correlation with other Spring observability components and simplify dashboard queries.

When configuring custom metrics, align your naming with the new conventions to avoid duplicate or confusing entries.