New in Spring MVC 3.1: CSRF Protection using RequestDataValueProcessor

>> Friday, April 13, 2012


As a software architect one of the common tasks I have to deal with is web applications security. Usually I would try to make sure that security is automatically enforced by the infrastructure, however this is not always that easy – sometimes the underlying frameworks don’t provide any built in support or configuration which globally turns on a security attribute. This is why the new interface in Spring MVC 3.1 seems to be very interesting: it provides a clean way to implement automatic CSRF protection.

(BTW – the lately released 'Pro Spring 3'book covers some of Spring 3.1 new features – such as profiles – but not the one discussed here).

CSRF - What Is It?

Cross-site request forgery (CSRF) is one of the most common web applications vulnerabilities (ranked number 5 on OWASP's Top 10 document). The following section, taken from Wikipedia, explains CSRF severity: "According to the United States Department of Homeland Security the most dangerous CSRF vulnerability ranks in at the 909th most dangerous software bug ever found, making this vulnerability more dangerous than most buffer overflows. Other severity metrics have been issued for CSRF vulnerabilities that result in remote code execution with root privileges as well as a vulnerability that can compromise a root certificate, which will completely undermine a public key infrastructure." (here)

Both links above include detailed information about CSRF attacks but it can be summarized in one short sentence: the core weakness the CSRF attacker is taking advantage of are predictable URLs and request bodies which changes the application state. As an example let’s assume a banking web application in which the 'wire money' form includes two fields: the amount to wire and the destination account number. An attacker can send an email to users which points to a page that silently posts a wire transaction request to the bank systems. If a user clicks that link, while his browser holds a valid session with the bank web site (for example in another tab), the wire transaction will be accepted by the bank systems. On the other hand if the wire form includes an unpredictable value (a secret) which is validated on submit the attack would fail. To mitigate CSRF attacks any request that changes the application state has to include an unpredictable secret token which must be validated before processing the request.

Before proceeding to the implementation details few things to notice:

  • I assume (and this is the way it should be!) that only POST requests change the application state
  • When discussing CSRF we often hear a sentence like: "but the attacker can use JavaScript to read your form structure and understand what the secret token is – so this CSRF token is actually useless". In practice the browser's same origin policy makes it very difficult for the attacker to read the CSRF token using JavaScript originated from his site.

Implementation Overview

I would like include a session private CSRF token in any form rendered to the UI and to enforce the existence and validity of that token on each POST request arriving to the application – so we basically have two components: out-bound form enrichment and in-bound request validation. The solution is fully automatic: once configured into the application all forms and POST requests will be CSRF secured without the need for any explicit action to be taken by application developers. In my solution the CSRF token will be HTTP session scoped - each session will have its own CSRF token valid to the entire session.

This is a utility class, used by both the in-bound and out-bound components. The class is responsible for managing the CSRF token for HTTP sessions. The key method in the class is getTokenForSession illustrated below (the full class source is on github - in this link):

static String getTokenForSession (HttpSession session) {
 String token = null;
 // I cannot allow more than one token on a session - in the case of two requests trying to
 // init the token concurrently.
 // Notice: in real life I wouldn't synchronize on the session instance. 
 // This should be done on an attribute on the session. But for the 
 // blog demo this is fine 
   synchronized (session) {
     token = (String) session.getAttribute(CSRF_TOKEN_FOR_SESSION_ATTR_NAME);
     if (null==token) {
       session.setAttribute(CSRF_TOKEN_FOR_SESSION_ATTR_NAME, token);
 return token;

The getTokenForSession method checks for the existence of a CSRF token as an attribute on an HTTP session, if one exists it returns its value otherwise it generates the session token, store it on the session and returns the token value to the caller. The method must synchronize on the session otherwise we might end with a caller getting a token which is no longer valid for the session (if more than one request trying to access the method concurrently and a token was not generated for the session yet). In my usage the token is a random GUID but any other random value is valid.

Form Rendering (out-bound)
I have to make sure that any form rendered using my Spring MVC based application will include the CSRF token as a hidden field. I do this by implementing the getExtraHiddenFields() method of the interface (remember since Spring 3.1). By implementing this method my class gets the opportunity to add hidden fields to any form rendered using Spring's form tag (<form:form....), obviously I will add a field with the CSRF token. Below is my implementation of the method (full class code on github):

public class CSRFRequestDataValueProcessor implements RequestDataValueProcessor {


 public Map<String,String> getExtraHiddenFields(HttpServletRequest request) {
   Map<String,String> hiddenFields = new HashMap<String,String>();
   return hiddenFields;

Still not done, for the processor to be invoked by Spring it has to be registered to Spring's RequestContext, the easiest way of doing that is to register an instance of my CSRFRequestDataValueProcessor as bean named 'requestDataValueProcessor' in the Bean Factory:

<!-- Data Value Processor -->
<bean name="requestDataValueProcessor" 

Enforcing CSRF Token Validity for  Incoming POST Request (in-bound)
The last part is to make sure that each incoming POST request includes a valid CSRF token for the session to which the request belongs. Usually the first approach JEE developers would adopt is to use a Servlet filter which checks to see if the current request is a POST one and if so it validates the existence of the CSRF token and its content.  The issue with that approach is the fact that the Servlet filter processing takes place before the request is routed to Spring's DispatcherServlet. In a multipart encoded forms (multipart/form-data) use case this would be proven wrong: since Spring has its own strategy to process multipart requests (look for MultipartResolver and MultipartHttpServletRequest in Spring's source) processing the request before Spring does will collide with Spring.

A more 'Spring like' way of doing so is using a HandlerInterceptor. Spring handler interceptors can be registered to add common pre or post processing to controllers. Unlike the Servlet filter those interceptors are a part of the Spring MVC request life cycle and it is fully synchronized with both multipart and simple (application/x-www-form-urlencoded) forms. Here is my relevant interceptor code (on github):

public class CSRFHandlerInterceptor extends HandlerInterceptorAdapter {


 public boolean preHandle(HttpServletRequest request, HttpServletResponse response, 
   Object handler) throws Exception {

   if (!request.getMethod().equalsIgnoreCase("POST") ) {
   // Not a POST - allow the request
       return true;
   } else {
     // This is a POST request - need to check the CSRF token
       String sessionToken = CSRFTokenManager.getTokenForSession(request.getSession());
       String requestToken = CSRFTokenManager.getTokenFromRequest(request);
       if (sessionToken.equals(requestToken)) {
         return true;
       } else {
         response.sendError(HttpServletResponse.SC_FORBIDDEN, "Bad or missing CSRF value");
         return false;

The last step is to register the interceptor into Spring's processing chain:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns=""
 xmlns:p="" ...

 <!-- Interceptor handlers -->
 <bean class=""/>

Code Examples

The source code is available as a standalone project in the SpringMVC-3.1-CSRF folder of this github repository. It includes a README.txt file which explains how to start the application using Maven (Jetty plugin) and access it from the browser.


Anonymous May 15, 2012 at 1:44 PM  


Do you have a unit test for testing the unique tokens?

Anonymous June 11, 2012 at 9:57 AM  

It should be noted that this solution does not play well with POST based AJAX calls, and obviously not for any form made without the form taglib. Do you have any recommended approaches to these scenarios?

Eyal Lupu June 11, 2012 at 10:48 AM  

For forms without the Spring's tag I don't have any solution but if you use any custom tag library developed by you than integrate it in your library (this is what I used to do in previous versions).

For AJAX – I register with each ajax request a filter (if I remember correctly using: $.ajaxPrefilter() ) which pushes the CSRF to each post request's data.

Anonymous August 1, 2012 at 9:58 PM  

Could you please post an example with ajaxPrefilter?

Aditya September 10, 2012 at 4:45 PM  

Please post an example of ajaxPrefilter...thanks

Anonymous October 10, 2012 at 2:44 AM  

What happens when there are multiple forms in the page ?

Will this solution work for multiple forms in the same page ?

Eyal Lupu October 11, 2012 at 12:40 PM  

yes - it works for multiple forms in a page as well.

Anonymous November 12, 2012 at 9:34 AM  

Alternative to ajaxPrefilter is to use setHeader() in the beforeSend function:

beforeSend: function ( xhr ) {
xhr.setRequestHeader('CSRFToken', csrf_token);

Tomek Kuprowski November 26, 2012 at 4:26 AM  

Interesting how does it deals with Spring Security (i mean login form)

phate January 30, 2013 at 12:20 AM  

Hi Eyal,

very interesting post. Just a quick question, in addition to the forms accessible from the browser I also use a command line client that I use to post the information.

The CSRF protection is detecting the client as invalid. Any ideas about how I can apply it?


Eyal Lupu January 30, 2013 at 1:10 AM  

H Phate,
If the field (parameter) is posted from the command line client it should work - it might a post issue that make things hard for Spring to extract the value.

I would start with curl - trying to make it work and then make sure that my command line is working the same way.

Also remember that each session has its own token - did you initiated a session with the command line client and maintained it (sending the JSESSIONID cookie)?


phate January 30, 2013 at 1:48 AM  

Hi again,

we SiteMinder for user authentication, so the session is created there. I was only managing the SM cookie, I will also add the JSESSIONID cookie and see.

Vaibhav Agarwal February 1, 2013 at 5:27 AM  


We have our application in Spring 3.1.2 MVC portlet. Can we also implement this solution to prevent CSRF attacks? I am in doubt whether this will work for SPRING MVC Portlet or not?


Anonymous February 2, 2013 at 12:27 AM  

I am not familiar with spring port lets so I wouldn't know to answer that...


Vaibhav Agarwal February 5, 2013 at 6:49 AM  

We have used the code and works well with SPRING MVC Portlets. We have about 200 portlets and it is working fine for 160 portlets, rest 40 portlets are having simple HTML form tag. Can you please help on how to use any custom tag library developed than integrate it in library?


Sachin Chaugule April 1, 2013 at 3:26 AM  

I want to implement same thing in spring mvc liferay portlet

Please help me.........

priomsrb April 1, 2013 at 3:39 PM  

How should I store the token if I want my application to be session-less? Is it safe to store the token as a cookie?

Thank you for the informative article.

priomsrb April 1, 2013 at 7:13 PM  

Actually I found the answer to my question above. Using cookies for the token will not work. This is explained in the OWASP CSRF cheat sheet: "Remember that all cookies, even the secret ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request."

priomsrb April 1, 2013 at 7:51 PM  

Sorry for spamming your comments section. Unfortunately, I can't find a way to edit my older comments.

To finally clarify, it is possible to store the token in the cookie. This is referred to as the "Double Submit Cookies" pattern. The Django framework uses this pattern.

priomsrb April 3, 2013 at 9:53 PM  

One thing to note is that using the CSRFRequestDataValueProcessor will make "method=GET" forms also have the CSRF token. This means that the token will be visible in the URL. The downsides of this are explained here:

So I have taken the approach of adding the hidden field manually to each of my POST forms (using ${sessionScope['CSRFTokenManager.tokenVal']}). If someone has a better way, please let me know.

Anonymous April 16, 2013 at 8:49 AM  

Very useful post, thanks.

Srđan Šrepfler June 1, 2013 at 4:31 PM  

In alternative, this solution does not require the random token but relies on the existence of a specific header, something which can be done only via an ajax call and which is bound to a domain, thus preventing CSRF

ruthran July 11, 2013 at 1:14 PM  

hi,nice topic..i have implementd in my local.but i got token value as null in each request.but i have token value in session.when will the getExtraHiddenFields method call?.i put one logger inside method..that is print never.pls tell the reason ASAP.

Rameez Raja August 28, 2013 at 3:31 AM  

I have gone through the description and code which is available. But I couldnt able to found out how the interceptor and session token genenreation happens before comes it comes to controller(CustomersController).. Do we need to configure in xml or call the interceptor in CustomersController?. Please clarify and thanks in advance.

Anonymous December 17, 2013 at 5:44 AM  

Will this solution work in case user has disabled cookies in her browser?

  © Blogger templates Sunset by 2008

Back to TOP