Per un REST-api sembra che sia sufficiente controllare la presenza di un'intestazione personalizzata per proteggersi dagli attacchi CSRF, ad es. client invia
"X-Requested-By: whatever"
e il server controlla la presenza di "X-Requested-By" e rilascia la richiesta se l'intestazione non viene trovata. Il valore dell'intestazione è irrilevante. Ecco come funziona CsrfProtectionFilter di Jersey 1.9 ed è descritto in questo post del blog: link . Il post sul blog si collega anche ai documenti NSA e Stanford che affermano che l'intestazione personalizzata è di per sé una protezione sufficiente:
The first method involves setting custom headers for each REST request such as X-XSRF-Header. The value of this header does not matter; simply the presence should prevent CSRF attacks. If a request comes into a REST endpoint without the custom header then the request should be dropped.
HTTP requests from a web browser performed via form, image, iframe, etc are unable to set custom HTTP headers. The only way to create a HTTP request from a browser with a custom HTTP header is to use a technology such as Javascript XMLHttpRequest or Flash. These technologies can set custom HTTP headers, but have security policies built in to prevent web sites from sending requests to each other unless specifically allowed by policy. This means that a website www.bad.com cannot send a request to http://bank.example.com with the custom header X-XSRFHeader unless they use a technology such as a XMLHttpRequest. That technology would prevent such a request from being made unless the bank.example.com domain specifically allowed it. This then results in a REST endpoint that can only be called via XMLHttpRequest (or similar technology).
It is important to note that this method also prevents any direct access from a web browser to that REST endpoint. Web applications using this approach will need to interface with their REST endpoints via XMLHttpRequest or similar technology.
Fonte: Linee guida per l'implementazione di REST
Sembra tuttavia che la maggior parte degli altri approcci suggerisca di generare un token e anche di convalidarlo sul server. È questo over-engineering? Quando un approccio "presenza di" è sicuro e quando è richiesta anche la convalida del token?