Put simply, CSRF tokens can be sniffed out of responses from the server unless the request/response are transmitted using encryption. Is this enough of a concern to worry about, or is it reasonable to allow the CSRF token to be transmitted via plaintext?

In our case, the framework we're using provides for exactly one CSRF token per session and our application has both HTTP and HTTPS forms to protect. My concern is that an attacker could sniff the CSRF token while the victim is visiting an HTTP page with a form on it and then entice the victim to visit a malicious HTTPS page which posts to a more sensitive HTTPS request handler on our application with the correct CSRF token (put there by the attacker who sniffed it earlier).

  • HTTPS will only protect you from man-in-the-middle scenarios. If you're using HTTP. a MitM can sniff everything required to hijack the session and perform the upgrade to HTTPS without much work, there are even applications that automate the process. In such a scenario any CSRF protection is completely useless. Otherwise SSL/TLS is just as vulnerable to CSRF attacks as without it, and any CSRF solution should be applied regardless of whether http or https is used. If your app requires that kind of security, implement a system that redirects port 80 to 443 in https and just stop using http. Commented Dec 4, 2015 at 4:24

2 Answers 2


Correct, your token needs to kept secret, or an attacker can duplicate the token. It's harder than borrowing the session cookie, but the basic principle is the same.

If you generate a unique CSRF token for every request & require it be used only once and on ever request, you can then ensure the token is not replayed. Even then it's still possible for the attacker to obtain the token & use it before the real user does.

Ultimately you will need to use HTTPS to be able to fully trust the CSRF token.

  • Awesome. I thought so, but needed a second opinion before trying to sell that notion to my boss, and I couldn't find any such recommendation just by googling for it. Thanks much for the answer! Commented Apr 21, 2014 at 15:00
  • Having the session cookie pretty much means game over. With that, the attacker could usually just skip login and request a page with an entirely new token with the form right in front of them and do whatever they want from there. So, though it may be harder than borrowing a session cookie, it's still less damaging. Commented Dec 4, 2015 at 4:29

If an attacker can sniff the CSRF token, then he can also sniff the session cookie and there would be no reason for him to launch a CSRF attack. Or am I missing something?

  • Ah. Good call. You are missing something, but only because I neglected to mention it. On the site we're maintaining, to protect against session hijacking/fixation, we store a nonce in the session and in a cookie when they go an SSL page. Every time they make an SSL request to change something on the server, we check the value of that cookie against the session value. So, sniffing a session id will only get them access to invoke non-SSL request handlers, not SSL request handlers. However, this mechanism won't protect against CSRF; only against session hijacking and/or fixation. Commented Apr 21, 2014 at 14:58
  • @user1483512 The reason CSRF tokens are effective is because an attacker cannot cause the token to be sent to the vulnerable service. The token is sent to the user's browser, not the attacker. The reason CSRF exists is because a user visits a malicious website that uses the user's browser to communicate with the service. Since cookies are handled automatically by the browser and used in each request, all cookie implementations are useless to prevent against CSRF attacks (including your nonce solution). Tokens are effective because they are dynamically and explicitly sent in the request itself. Commented Dec 4, 2015 at 3:59

You must log in to answer this question.

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