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...
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.
Sometimes URLs are a double–edged sword for our site because they can expose too many details about the internal structure of our web application and malicious users could exploit them to perform a cross-site request forgery.
To me, all this means is that it hides the url parameters so that the users can't find as much about the workings of your app. To simply assume that this is a means for protecting your app entirely from CSRF would be stupid.