Are JAXRS restful services prone to CSRF attack when content type negotiation is enabled?

Question

I have a RESTful API which has annotations like @Consumes(MediaType.JSON) - in that case, would the CSRF attack still be possible on such a service? I've been tinkering with securing my services with CSRFGuard on server side or having a double submit from client side. However when I tried to POST requests using FORM with enctype="text/plain", it didn't work. The technique is explained here This works if I have MediaType.APPLICATION_FORM_URLENCODED in my consumes annotation. The content negotiation is useful when I'm using POST/PUT/DELETE verbs but GET is still accessible which might need looking into.

Any suggestions or inputs would be great, also please let me know if you need more info.

Cheers

Answer 1

JAX-RS is designed to create REST API which is supposed to be stateless. The Cross Site Request Forgery is NOT a problem with stateless applications.

The way Cross Site Request Forgery works is someone may trick you to click on a link or open a link in your browser which will direct you to a site in which you are logged in, for example some online forum. Since you are already logged in on that forum the attacker can construct a url, say something like this: someforum.com/deletethread?id=23454

That forum program, being badly designed will recognize you based on the session cookie and will confirm that you have the capability to delete the thread and will in fact delete that thread.

All because the program authenticated you based on the session cookie (on even based on "remember me" cookie)

With RESTful API there is no cookie, no state is maintaned between requests, so there is no need to protect against session hijacking.

The way you usually authenticate with RESTFul api is be sending some additional headers. If someone tricks you into clicking on a url that points to restful API the browser is not going to send that extra headers, so there is no risk.

In short - if REST API is designed the way it supposed to be - stateless, then there is no risk of cross site forgery and no need to CSRF protection.