Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Usually, the web server that is serving a page includes the CSRF token inside the HTML. However when I'm using a cross-origin REST API, there is no "initial" page that could include the CSRF token.
My idea is to respond with a CSRF token after the user logs in, but I'm not entirely sure if this protects against a CSRF-attack?
What you are referring to is a stateless API request where you need to prevent CSRF on the initial caller request.
What you need here is a mechanism called a double-submit-cookie
But you have not made it clear which endpoint you control so I am unable to derive if this solution will work for you because in a stateless scenario there are limited options, and even less ability to implement security controls when you have no control over both endpoints.
It does protect against CSRF.
Logging in proves the user knows his credentials. You can embed those CSRF tokens in the result of logging in.
The only way that could be fooled would be a service that asks for the password of the user, and behind the scenes logs in and uses the API in the name of the user. That's no longer a CSRF attack but rather a man-in-the-middle attack.
But you don't necessarily need a separate CSRF token -- usually that's required only when using cookies for authentication.
CSRF attacks work by the user being logged in in a web browser and the cookies being the proof that the user has been logged in. Then a dangerous web site could embed:
<script src="http://your.api/get/request?id=1" />
...which forges a GET request that includes authentication cookies. It's even possible to create a form to forge a POST request without the user's knowledge (the user isn't going to look at the source code of the site, the user thinks the POST is to the attacker's site not to the attacked site). If those requests have side-effects, the side-effects will be executed, like deleting something of value.
However, if your API doesn't use cookies for authentication but for example uses some kind of bearer token instead, that's already CSRF-safe. These bearer tokens don't need to be used with separate CSRF tokens, because a <script> or <img> tag or <form> doesn't cause inclusion of those bearer tokens automatically in the request.
