I'm working on a web application which stores an authentication token in a cookie.

The only CSRF-protection is referrer checking.

I am considering improving this by moving the authentication token from cookies to a custom header, such as X-AuthToken.

The application is a single page application created using JavaScript.

I believe this should be a robust protection against CSRF-attacks, because if an evil site forces a users browser to do a HTTP POST, the auth header won't be included and the request will fail.

The auth token is generated on a per-session basis.

Am I right that this would offer CSRF protection or am I missing something?


1 Answer 1


Short answer: yes, it would be secure if correctly implemented (long enough, random, unique tokens, one per session, etc).

Long answer: If you decide to add a custom header to the requests sent to the server using JavaScript code, it is similar to sending an anti-CSRF value in the POST parameters (the more often used approach).

POST /test 
Host: www.example.com 
X-AuthToken: unique_random_value



POST /test 
Host: www.example.com


So it's up to you to decide which option is easier to implement, but both should work in a secure manner.

  • 1
    adding on that: moving the auth token from the cookies has an effect on user experience - users will not be able to stay signed in to your website... this is why authentication tokens are usually kept in cookies. This is another good reason to keep the auth token in the cookies and implement an anti CSRF token in the headers
    – aviv
    Commented Jan 27, 2015 at 16:18
  • The name may be misleading, I understand that X-AuthToken authenticates the requests, but it is not the session token, which will be stored using cookies.
    – Dinu
    Commented Jan 27, 2015 at 17:15
  • For downsides to using thie request (Flash vulnerabilities), see this answer.
    – Anders
    Commented Jan 6, 2017 at 21:00

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