I have a Angular web app that interacts with a REST-API. Requests are authenticated with a JWT Bearer token. I now want to add support for Windows-Authentication.

My current plan is to add a POST-Endpoint /token to the REST-API, which accepts Windows-Authentication and returns a JWT. This JWT is then used in JavaScript as a Bearer token to authenticate XHRs to the REST-API.

On first glance, this should prevent CSRF, since it requires two POST-Requests to modify the state of the application. The <form>-based examples of CSRF I found only submit one POST request, and the response is not visible to the attacker.

Is there something I am missing?

This scenario is similar, except that it is using cookies instead of Windows-Authentication.


2 Answers 2


CSRF only applies where security credentials are automatically included by the browser on every request to a particualr domain, even when the request has been forged by an attacker. This most commonly affects session cookies.

For most sites, browser requests automatically include any credentials associated with the site, such as the user’s session cookie, IP address, Windows domain credentials, and so forth. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish between the forged request sent by the victim and a legitimate request sent by the victim.

from https://owasp.org/www-community/attacks/csrf

It sounds like you're probably sending an Authorization header with the bearer token inside there. If that is the case, then any state-changing request that expects this header is most likely safe from CSRF. Your Angular application is attaching the token to each request - any requests from outside of your application will not have this token applied automatically by the browser.

Windows authentication itself might be an issue, but by only allowing Windows authentication to be used to retreive a new JWT, and not for any subsequent state-changing requests, you should be fine.

The fact that two POST requests are used is not what is preventing CSRF here (which I mention because its a commom misconception), it is the fact that the 2nd state-changing POST request only accepts an Authorization header.


You need to make sure that your token endpoint has an access control origin policy, otherwise the attacker could request your xsrf token and then use it to modify the state.

As long as you are assigning a token to a request from a secure origin, then validating that token in your post handler, you should be ok.

  • The API and Angular site are hosted on the same Origin. Therefore, no CORS is allowed on the API. As far as i understand, the Access-Control-Allow-Origin is only necessary, when CORS is allowed: "By default, Site B's pages are not accessible to any other origin" stackoverflow.com/questions/10636611/…
    – webbertee
    Commented Jun 10, 2020 at 8:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .