Right now, the current 1.4 web services don't provide a great deal of strong protection against xsrf. The current approach is not really safe enough, and so right now, unless we find a way to fix this, we'd need to recommend opening up that section of urls only to trusted hosts (i.e. servers). While this seems like a big limitation, if you restrict by client-side certificate you could allow access from dedicated non-browser mobile clients but not web browsers.
There is another option though, in that we could allow for some sort of digital signing of a component of a request. Unfortunately, this is going to require going with perl modules (which don't have a perfect cpantester record) or pgcrypto as an extension. However, you could have a public key, and you could check the signature of a specific set of information.
A third option would be a pre-shared auth key that would be submitted with every request, and tied to the user. The positive side is that it would be simple. The negative side is that the tokens would be long-term valuable and if compromised would provide a means to exploit xsrf via the browser if the user accounts are shared.
For now (1.4) I think recommending client-side certs would provide the most protection, but while this provides good protection for dedicated clients it means effectively locking browsers out of the restful web services.
Our current csrf protections for the web app, while better on the browser than any others that could be implemented there with RESTful principles, is certainly not RESTful, as it requires effectively pre-authorizing every write request (i.e. get the authorization token then add it to the post request). This requires a double-round trip to make a write effective.
Anyway, feedback is requested.
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in.