CSRF security risks if Validation token in header instead of POST body

Most widely found solution on Searching for CSRF prevention techiniques is what MVCAntiForgeryToken (comes with MVC 3) implements, where client of the server has to post the validation token in POST body. On server side it will be validated against the token present in Cookie.

Is it equally secure to send the validation token in a custom header, and on server side validat开发者_如何学Pythone value of custom token with one present in cookie ?

---

It is even more secure :) because even if attacker can obtain a valid csrf token for current transaction, he would have to institute a cross domain ajax request to include custom headers in request. And if user has disabled js in his browser then the attacker is toasted :). It can however be overridden with java applets... but you know if users are uneducated and attacker is really motivated there is very little you can do;).

But there is an issue not all custom headers will be forwarded in case a user is accessing us via firewall or corporate proxy. So i think this is the main reason for using field instead of a custom header. Although there is a header that prevents XSRF attacks: Origin, The web origin concept also as additional information Content Security Policy 1.1 it is only a draft but some interesting ideas are presented there.