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?

  • 1
    The alternative is to expose a service that returns a CSRF token, which should be included in the next request. Being that web services typically use header-based authentication, I'm not sure if a CSRF token applies. Oct 29, 2021 at 12:24
  • There are two common solutions - csrf in the header with cors (if you control web servers which apis you call) or samesite cookie. Other scenarios may include defining additional domains. Oct 31, 2021 at 0:30
  • Relevant: Should I use CSRF protection on a REST API?
    – John Wu
    Dec 15, 2021 at 4:19

2 Answers 2


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.