Consider I’m creating a RESTful API (like Twitter API) and I need only a single key token to access the endpoint GET /messages
.
- The token needs to be sent via header
access_token
for example. - If I don’t pass the token I’ll get an 4xx error.
In the RESTful API scenario, is this all needed to protect against CSRF attacks? I mean, in RESTful APIs I’m not using Cookies to manager a user session, since the idea here is to not be a session (Stateless is one of the principles of REST).
Am I forgetting something or is this correct? I don’t see why I would need a anti CSRF token
besides my access token.
Thanks in advance!
2
Answers
@Bart Firstly CSRF attacks are usually from a trusted user. Which means that the client has successfully authenticated himself by maybe passing a valid token in case of a rest API. The attack could be by passing let’s say a javascript which can change the state of a resource. So just having a single key token won’t really help to avoid CSRF attacks.
Please refer to below URL for more reference on CSRF :-
https://en.wikipedia.org/wiki/Cross-site_request_forgery
Most of the frameworks like Spring have inbuilt support for CSRF.
Short answer: if your access_token is not a cookie, yes, it’s enough to protect you against CSRF.
Long answer:
A CSRF attack can only happen when HTTP client automatically sends some authentication data(usually cookies) to server. The key point is attacker do not need to know the Cookie, it’s is automatically sent if web user accesses 2 sites(your site and the attacker’s site) using the same browser.
To anti CSRF, server sends to client a private token that browser does not automatically send it to server(so it’s must not be a cookie). The developer has to write code to attach the token to each subsequent request.
CSRF is an issue for using Cookie by Web browser, if you are developing restful API that is not used by web browser, usually, you do not need to care about CSRF