I created one RESTful API using spring. I am transmitting a secret key as HttpOnly & Secure cookie with login response. After login every rest request will check with that cookie and update it every time.

Is it possible that my website is vulnerable to CSRF? I am using spring MVC & Apache 2.4

  • Please use spell check and proper punctuation. English is hard, but at-least follow the basic rules when posting. Also, yes your app is vulnerable as hell.
    – rook
    Dec 23, 2014 at 15:34

1 Answer 1


First of all, CSRF and XSRF reffer both to Cross Site Request Forgery.

Second of all, unless you put an anti-CSRF token in a cookie, atleast the HttpOnly attribute should be set if possible.

There are situations where you can't set the HttpOnly attribute, an example is when you use javascript code which require to be able to read the value of the cookie (AngularJS).

If you serve your REST API over HTTPS, then the Secure attribute on the anti-CSRF cookie should be set as well.

This URL explains how to use and configure anti-CSRF tokens in the Spring MVC framework.

This URL explains how to use anti-CSRF tokens in PHP without using a PHP framework.

There are situation where an attacker is able to steal HttpOnly cookies:

  1. The HTTP TRACE method is enabled
  2. Outdated Apache (CVE-2012-0053) (< v2.2.22)

If these two conditions are not met, based on your description, I would say your code is sufficiently protected against CSRF attacks, especially since you use request based anti-CSRF tokens (I know banks that don't even do this). Good job! :)

However, do not try to re-invent the wheel. Personally I would try to implement a proper anti CSRF protection using the Spring MVE framework.

  • 6
    A cookie can't prevent CSRF, the point of CSRF is that you are riding on a session because all requests to a domain contain a cookie. Perhaps you are confused by how double-submit CSRF tokens work?
    – rook
    Dec 23, 2014 at 15:36
  • There are way to do it, combination of a cookie and the same value in the HTTP response header. These are checked against eachother and checked on the server side. Several banks use these methods (of which I am not a huge fan... at all)
    – Jeroen
    Dec 23, 2014 at 17:18
  • 2
    What you just described in your comment is a 'double submit cookie' and referenced by the OWASP CSRF prevention cheat sheet. What you described in your post is a vulnerability. A cookie alone cannot prevent CSRF.
    – rook
    Dec 25, 2014 at 17:38
  • 2
    Rook is correct. Cookies are sent regardless of the source, that's why you need to submit the anti-CSRF token through other means. The link he provided provides a correct explanation of CSRF and CSRF prevention. Dec 26, 2014 at 8:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .