[zaroth]

It's somewhat bizarre to obfuscate the URL thinking it will stop CSRF, if there's no anti-forgery token embedded within.

As Fabian says, just do the CSRF with the encrypted URL if it's not stateful. When Apache Wicket does add state, apparently it's just a small incrementing integer. Like an 8 bit anti-forgery token.

But all of this seems like so much over-engineering when one line of Javascript to add a non-standard request header, and one line on the server to fail if it's not present -- that's all you need?!

What I'm wondering, if you add an X- header with no actual token, do we agree that's enough these days? I remember an old Flash version which allowed adding X-headers outside the SOP, is that the only reason it's not considered fully safe? I think if you're running outdated Flash your machine is completely owned anyway and Anti-CSRF won't make a difference.

[1] - http://security.stackexchange.com/questions/23371/csrf-prote...

[steakejjs]

You'll notice a lot of people just have X-CSRF.* header (Stripe for example if you want to check one out). In my opinion you might as well just go the full 9 and actually implement an anti-CSRF solution instead of a quick hack.

x-Requested-By works but your webapp can be built in a way that things like insecure redirects fool you app.

The best solution is just to use tokens.