Should I use CSRF protection on Rest API endpoints?

Question

Quick note: this is not a duplicate of CSRF protection with custom headers (and without validating token) despite some overlap. That post discusses how to perform CSRF protection on Rest endpoints without discussing if it is actually necessary. Indeed, many CSRF/Rest questions I've read on this site talk about securing the endpoints via CSRF tokens without actually discussing whether or not it is necessary. Hence this question.

Is CSRF Protection necessary for Rest API endpoints?

I've seen lots of discussion about securing REST endpoints against CSRF attacks, but having given the topic lots of thought, I'm very certain that CSRF tokens on a REST endpoint grant zero additional protection. As such, enabling CSRF protection on a REST endpoint just introduces some useless code to your application, and I think it should be skipped. I may be missing something though, hence this question. I think it will help to keep in mind why CSRF protection is necessary in the first place, and the attack vectors it protects against:

Why CSRF?

It really boils down to the browsers ability to automatically present login credentials for any request by sending along cookies. If a session id is stored in a cookie the browser will automatically send it along with all requests that go back to the original website. This means that an attacker doesn't actually have to know authentication details to take an action as the victim user. Rather, the attacker just has to trick the victims browser into making a request, and the credentials to authenticate the request will ride along for free.

Enter a REST API

Rest API endpoints have a very important difference from other requests: they are specifically stateless, and should never accept/use data from either a cookie or session. As a result, a REST API that sticks to the standard is automatically immune to such an attack. Even if a cookie was sent up by the browser, any credentials associated with the cookie would be completely ignored. Authentication of calls to a REST API are done in a completely different fashion. The most common solution is to have some sort of authentication key (an OAuth Token or the like) which is sent along in the header somewhere or possibly in the request body itself.

Since authentication is application-specific, and since the browser itself doesn't know what the authentication token is, there is no way for a browser to automatically provide authentication credentials even if it is somehow tricked into visiting the API endpoint. As a result, a cookie-less REST endpoint is completely immune from CSRF attacks.

Or am I missing something?

Answer 1

I wasn't originally aiming for a self-answer, but after more reading I've come up with what I believe to be a comprehensive answer that also explains why some might still be interested in CSRF protection on REST endpoints.

No cookies = No CSRF

It really is that simple. Browsers send cookies along with all requests. CSRF attacks depend upon this behavior. If you do not use cookies, and don't rely on cookies for authentication, then there is absolutely no room for CSRF attacks, and no reason to put in CSRF protection. If you have cookies, especially if you use them for authentication, then you need CSRF protection. If all you want to know is "Do I need CSRF protection for my API endpoint?" you can stop right here and leave with your answer. Otherwise, the devil is in the details.

h/t to paj28: While cookies are the primary attack vector for CSRF attacks, you are also vulnerable if you use HTTP/Basic authentication. More generally, if the browser is able automatically pass along login credentials for your app, then CSRF matters. In my experience cookies are the most common technology being exploited to make CSRF happen, but there are some other authentication methods that are used which can result in the same vulnerability.

REST = Stateless

If you ask someone "what is REST" you will get variety of answers that discuss a variety of different properties. You can see as much because someone asked that question on stack overflow: https://stackoverflow.com/questions/671118/what-exactly-is-restful-programming

One property of REST that I have always relied upon is that it is stateless. The application itself has state of course. If you can't store data in a database somewhere, your application is going to be pretty limited. In this case though, stateless has a very specific and important meaning: REST applications don't track state for the client-side application. If you are using sessions, then you are (almost certainly) keeping track of client-side state, and you are not a REST-full application. So an application that uses sessions (especially for logins) that are tracked via cookies is not a REST-full application (IMO), and is certainly vulnerable to CSRF attacks, even if it otherwise looks like a REST application.

I think it is worth a quick note that one reason that client-side statelessness is important for REST applications is that the ability of intermediaries to cache responses is also a desirable part of the REST paradigm. As long as the application is tracking client-side state, caching is not possible.

Rest ≠ Cookieless

For these reasons, I initially assumed that a fully-compliant REST application would never need sessions, never need cookies, and therefore never need CSRF security. However, there is at least one use-case that may prefer cookies anyway: persistent logins.

Consider a typical client-side (in this case browser, not mobile) web application. You get started by logging in, which uses a REST API to validate user credentials and in return is given a token to authorize future requests. For single page applications, you can just keep that token in memory, but doing so will effectively log the user out if they close the page. As a result, it would be good to persist the state somewhere that can last longer than a single browser session. Local storage is an option, but is also vulnerable to XSS attacks: a successful XSS attack can result in the attacker grabbing your login tokens and sending them off to the attacker to be used at their discretion.

For this reason, I have seen some suggest using cookies to store login tokens. With a cookie you can set the http-only flag, which prevents the application from reading the cookie after it is set. As a result, in the event of an XSS attack, the attacker can still make calls on your behalf, but they can't walk away with the authorization token all together. This use of cookies doesn't directly violate the statelessness requirement of REST because the server still isn't tracking client-side state. It is just looking for authentication credentials in a cookie, rather than the header.

I mention this because it is potentially a legitimate reason to use cookies with a REST API, although it is obviously up to a given application to balance the various security and usability concerns. I would personally try to avoid using cookies with REST APIs, but there may very well be reasons to use them anyway. Either way, the overall answer is simple: if you are using cookies (or other authentication methods that the browser can do automatically) then you need CSRF protection. If you aren't using cookies then you don't.

Answer 2

Whether or not CSRF protection is needed is based on 2 factors: -

Is the request doing a state changing action (not the same as REST API Statelessness) - State changing actions are any action that will change the state of the application.. for example delete something, add something, update something. These are actions using which the application will change the backed state of the user. All Post requests and a few Get requests will come under this category. REST APIs can have state changing actions.

Is the authentication provided by browser (not limited to cookies) - CSRF happens because authentication information is included in the request by browser irrespective of whether the request was started by the user, or some other open tab. So any kind of authentication in which browser can self include information needs CSRF protection. That includes both cookie based sessions and basic authentication.

For all requests that fall in above 2 categories CSRF protection is needed.

Answer 3

"there is no way for a browser to automatically provide authentication credentials even if it is somehow tricked into visiting the API endpoint"

Just be careful on private networks using integrated windows/kerberos authentication. In this scenario the brower will automatcially provide credentials (kerberos or NTLM token) if configured to do so.

So - I believe in this case CSRF is required.

Answer 4

One thing I would add to the other answers is that CSRF protection is necessary only in the domain and path of the cookie in question. Or put another way:

Authorization != Authentication
Cookies == Authentication
Token == Authorization

This is relevant to the implementation of persistent logins (your 3rd point). If you affix your cookies to login.example.com, which hosts your login UI and your /authorize endpoint, then you can run an implicit OAuth flow every few minutes without requiring a new login (e.g. no password dialog). The client can go ahead and send the access token thus acquired to api.example.com without CSRF, as no cookies will be sent to that host.

So, you can still safely avoid dealing with CSRF on your REST APIs. But your login / authentication server better be bullet-proof (and CSRF protected).

Answer 5

Rest API endpoints have a very important difference from other requests: they are specifically stateless, and should never accept/use data from either a cookie or session.

If that is how you define "REST API", then no CSRF is possible. CSRF, also called "session riding" [citation], obviously won't work if there is no session to "ride."

Answer 6

Answer : If you store the token in the localStorage and append it to your requests with JS, it would automatically guarantee CSRF protection (by the nature of the attack)

Addendum : As of whether it is more safe to use http-only cookies rather than localStorage (making it seem like this way of having CSRF protection would create a problem in case of XSS) : it is actually not. It would just make it a tiny bit harder for the attacker who is in control of JS on your site through an exploited XSS. @bobince have explained that with better words : Does setting httponly prevent stealing a session using XSS?

XSS is application level vulnerability, but its effects can be mitigated by limiting the power of the token through the usage of claims (restrict to minimum necessary)

Answer 7

There's a small specific caveat to existing answers that I'd like to add. While Conor is right that cookies are the only form of locally stored authentication data sent along all requests, they're not the only form of locally stored authentication data used by websites. What this means is, if a site decides to keep their JWTs/Session tokens in something like LocalStorage or SessionStorage, these can still sometimes be automatically pulled out via javascript and then used without user interaction. That means it is sometimes still possible to perform CSRF attacks "once removed" by redirecting a user to a domain-matching frontend URI that then sends the creds along. This can be accomplished in a more direct way if you have reflected XSS, but there are cases where this is unnecessary and such pages+scripts already exist.

In these cases, the problem isn't the lack of CSRF tokens on the REST API; it's the lack of tokens on the endpoints of whatever frontend is interacting with it.