Is CSRF possible in an SSR SPA with cookie authentication?

Question

I have a Single-Page Application, which is basically a consumer to my API which authenticates using the Authorization header. Now because I do server-side-rendering, I need to authenticate on the initial request, which means I need to use cookies to store the auth token.

Now as far as I understand, CSRF works like this in a typical website:

• Find an endpoint that does something harmful like /delete-account which authenticates with cookies
• In example.com, put a <img href="http://mywebsite.com/delete-account"> (or whatever for a POST request)

However, to me, it looks like that it is impossible for CSRF attacks to happen in the case of an SPA, even if authentication token is sent as a cookie. The normal procedure is a bit like:

• User visits a page, say /account
• Server renders page as per the authenticated user (given the auth cookie)
• Web page is returned
• Now if the user wants to delete their account, they could press the button, which would send a request to the API that authenticates requests only by Authorization header

Now in a CSRF attack:

• <img href="/account">
• Server renders and returns webpage
• Umm, nothing happens?

I mean I can't think of a way I can be vulnerable to CSRF in this situation, even if I use cookies for authentication, and as far as I understand, CSRF attacks can't scrape data out of web pages, so returning sensitive data shouldn't matter, as long as it doesn't trigger an action.

So my question is, is it fine to not implement any sort of CSRF protection in this case? I'm so afraid of having a security issue regarding that.

Answer 1

Now if the user wants to delete their account, they could press the button, which would send a request to the API that authenticates requests only by Authorization header

Ultimately, it sends a request to perform an action which needs to be authenticated somehow. And, since you're using Authorization header for authentication, it somehow prevents CSRF unless you're using HTTP Basic Auth or NTLM. These authentication tokens are sent in each request similar to cookies.

I mean I can't think of a way I can be vulnerable to CSRF in this situation, even if I use cookies for authentication, and as far as I understand, CSRF attacks can't scrape data out of web pages, so returning sensitive data shouldn't matter, as long as it doesn't trigger an action

There are situations you might find yourself vulnerable to CSRF, here are few;

1. What if your server accepts any of two i.e. either cookies or token?

-> I had recently encountered the same. The application would either need cookies or auth token. Since, cookies are always sent, you're assumed to be authenticated and your request gets processed leaving you vulnerable to CSRF again assuming your application allows sending Authorization token from any domain.

2. What if your application leaks auth token which can be read cross-domain?

-> I have seen a number of apps fetching tokens from a predefined endpoint which somehow can be read crossdomain. Some possibilities are, JSONP, CORS, crossdomain.xml, JSON Hijacking, etc. This again leads to CSRF.

even if I use cookies for authentication

That is always vulnerable, you just need to play with final request which is an API request in your case.

So my question is, is it fine to not implement any sort of CSRF protection in this case? I'm so afraid of having a security issue regarding that

As a matter of fact, yes. Also, make sure you whitelist domains which can make request to your API and return Access-Control-Allow-Credentials: false. This, in my opinion, makes it fairly safe against CSRF- considering points mentioned above.

Answer 2

Firstly, it's important to understand the following: you should implement something to authenticate a user and you should implement something to authenticate a request (Anti-CSRF). CSRF Attack use a session of a victim, so if your Authorization header value is the same for all session, your application could be vulnerable to a CSRF-attack, because your application validates only a user session, it needs to validates a request and this is possible using a token with the following features:

• Long enough.
• Pseudo-random.
• Unique value.
• One per-request.

Firstly, you should validate user session, if it's a valid user and her/his permissions or role, after that you should validate the request through the token, if it's a valid token then you can permit the request.

I hope this information helps you.