Expected Behavior When using the @PreFilter and @PostFilter annotations with Kotlin's Collection and Map, the filtering logic should be applied as it is in Java code.

Current Behavior Any Kotlin Collections and empty Maps throw an UnsupportedOperationException as these types in Kotlin are immutable, but the implementation of DefaultMethodSecurityExpressionHandler attempts to mutate their state.

Minimal reproducible example: - #15094

Context For Collections, that happens in the following lines: https://github.com/spring-projects/spring-security/blob/64e2a2ff8b493aa0298043128b7329e2a7362e4b/core/src/main/java/org/springframework/security/access/expression/method/DefaultMethodSecurityExpressionHandler.java#L154-L155

For Mapss, the same happens in the following lines: https://github.com/spring-projects/spring-security/blob/64e2a2ff8b493aa0298043128b7329e2a7362e4b/core/src/main/java/org/springframework/security/access/expression/method/DefaultMethodSecurityExpressionHandler.java#L192-L193

This fact is also reflected in the javadoc: https://github.com/spring-projects/spring-security/blob/64e2a2ff8b493aa0298043128b7329e2a7362e4b/core/src/main/java/org/springframework/security/access/expression/method/DefaultMethodSecurityExpressionHandler.java#L115-L117

Moreover, the official Spring Security documentation on Method Security, specifically the sections Filtering Method Parameters with @PreFilter and Filtering Method Results with @PostFilter clearly mention that "@PreFilter/@PostFilter is not yet supported for Kotlin-specific data types; for that reason, only Java snippets are shown".

How has this issue affected you? It has prevented me from being able to use the @PreFilter and @PostFilter annotations in my Spring Boot projects written in Kotlin.

What other alternatives have you considered? Writing my own implementation of the MethodSecurityExpressionHandler interface.

This works for my usecase, but I would like the whole Spring Security community to benefit and be able to use the @PreFilter/@PostFilter with Kotlin by default. Additionally, implementing this solution within my own codebase increases internal dependencies and liabilities.

What are you trying to accomplish? Add first-party support for the Kotlin data types by making DefaultMethodSecurityExpressionHandler work with them.

Are you aware of any workarounds? Using the mutable variants of Kotlin's read-only data types.

This does not work for my usecase as it undermines the benefits of Kotlin's (preferred) in-built immutable types.

Action Items Proposed solution in the following pull request: - #15095