It was a neat little idea to play around with when I first wrote the post, since setting X-Requested-With on an arbitrary domain requires a violation of the same-origin policy. But as I point out at the top of the post, there was at least one recent case of a same-origin violation (via the Flash 307 bug) that allowed for arbitrary headers to be written.
CSRF tokens, whether they're in headers or in a form, are the more secure way to prevent an attack. They require a violation of the same-origin policy where an attacker can read (at least part of) the HTTP response sent by your server. If an attacker can do that, you already have larger issues.
I don't think that HTTP headers are enough and feel that setting csrf tokens is the best approach to this. My reasoning behind this is that there are a lot of privacy plugins[1] that people use that interfere with the headers and using referer header is even worse because a lot of websites have redirection vulnerabilities eg if you want to be returned to the page you were at after logging into a website the url would be something like login.php?url=/page/id , a lot of websites do not sanatize this which would render this useless. It is also not an option for some websites that must have a function like this, a prime example of this is Youtube[2] which uses csrf token (hidden fields) in forms to mitigate this issue.
It was a neat little idea to play around with when I first wrote the post, since setting X-Requested-With on an arbitrary domain requires a violation of the same-origin policy. But as I point out at the top of the post, there was at least one recent case of a same-origin violation (via the Flash 307 bug) that allowed for arbitrary headers to be written.
CSRF tokens, whether they're in headers or in a form, are the more secure way to prevent an attack. They require a violation of the same-origin policy where an attacker can read (at least part of) the HTTP response sent by your server. If an attacker can do that, you already have larger issues.