This recipe tackles two issues, namely the prevention of CSRF and session fixation, in Spring MVC applications. When it comes to session fixation, Spring Security provides default protection which invalidates the previous sessions but copies all session attributes to the newly created one. This mechanism is called the http.sessionManagement().sessionFixation().migrateSession() type of preventing session fixation attacks. But there are two more options developers can use, and these are newSession() and none(). newSession() is preferred for this recipe because it deletes the entire past sessions, including session data, which gives confidence that no exploits can penetrate through older sessions or use the session data. The method none() is the scariest because it does not delete any previous sessions.

On the other hand, deleting http.csrf().disable() means the security model enables CSRF support for the application. Enabling CRSF support means injecting or customizing the CsrfTokenRepository interface that will generate tokens to be stored in every specific session created by Spring Security. The default repository is session-based and is derived from the HttpSessionCsrfTokenRepository class, but another solution is to implement OncePerRequestFilter to generate and store tokens without using any sessions. Customizing filters such as OncePerRequestFilter opens solutions for AJAX or plain JavaScript to interact with the tokenization processes through the retrieval of the two generated tokens, XSRF-TOKEN and X-XSRF-TOKEN.

This recipe uses org.springframework.security.web.csrf.CookieCsrfTokenRepository, which generates and stores the XSRF-TOKEN as cookie data:

In order for CSRF support to work with sessions, all form transactions and navigations must be in POST request transactions, with the use of the Spring Form tag library <form:form> to spare us from creating AJAX to manually generate and attach the token per view page. Any access to authenticated pages without the specified token will give users the HTTP status 404, which indicates that the application is sensitive to CSRF.

Anonymous pages are not included in the CSRF tokenization process, so hyperlinks and typical HTML forms can be used on these pages.