SEC-1950: Defensively invoke SecurityContextHolder.clearContext() in FilterChainProxy

[spring-projects-issues]

Rob Winch (Migrated from SEC-1950) said:

In situations where applications try to obtain the SecurityContext globally it may cause a memory leak if the application uses security=none and the SecurityContextHolder is even read from. A similar situation can occur if users manually create the filter chain and do not properly add the SecurityContextPersistenceFilter to the FilterChainProxy. In order to be defensive about memory leaks, it would be good to call SecurityContextHolder.clearContext() in the FilterChainProxy itself.

[spring-projects-issues]

Rob Winch said:

Note that there is not a memory leak even prior to this issue assuming Spring Security is being used correctly. This is just a measure that allows it to get cleaned up properly even when used improperly. There are still edge cases where if used improperly, there would be a memory leak. For example if the user invokes SecurityContext.getContext() and does not add the FilterChainProxy (i.e. springSecurityFilterChain) to the web.xml there will still be a leak. However, there is little we can do about these other situations.

[spring-projects-issues]

This issue relates to #2252