XSRF antiforgery: Asp.Net Core 2 WebApi (not MVC) + separate Server for Angular is possible?

Question

I'm using Asp.Net Core Webapi 2 with no static content as a backend server + nginx on a separate machine to serve Angular 7 application. Here is the question: does it have sence to try to use xrsf antiforgery protection like services.AddAntiforgery(options => options.HeaderName = "X-XSRF-TOKEN"); in case of splitted back and front machines? As far as I understand I have to manage some kind of state between these two servers to provide corresponding cookie from Nginx which backend server will accept.

Answer 1

If I have understood the question correctly, you want to know how to protect your webapp from CSRF attack.

Your APIs are hosted in a backend web server, whereas the Angular static contents are hosted in nginx.

The idea is explained in Angular docs . You need to set the cookie XSRF-TOKEN (default name) in authentication REST response. The cookie should be secure but readable using javascript (non- httpOnly ). You can set the value of the cookie to something unique for the user session (ideally a cryptographically generated random number). Here, onwards in every subsequent request, Angular HttpClient would send the cookie value in the request header X-XSRF-TOKEN and the server needs to validate if the cookie value and the request header value are correct. Note that the access token cookie would also accompany the request (as usual in token based authentication). Thus in every valid API call, your web server would receive the access token in cookie header and the XSRF cookie value in custom XSRF header and XSRF cookie header. If the XSRF header is missing or the values do not match, the server rejects the request.

So, the solution is stateless and managed by storing values in cookie which accompany every request (unless you also maintain the XSRF cookie value in the server for more strict validation).

In your setup, the cookie set by the server is not be visible to the Angular static files served by nginx due to same-origin policy. You can however resolve the issue in one of the following ways:

1. If your web API server and static file server are accessed using different IPs (say 172.168.1.1 and 172.168.2.2) or different domains (say webapi.com or static.com), you need to configure the web api server to set the following headers in response to allow the static file server (172.168.2.2 or static.com) read the cookies: Access-Control-Allow-Origin: https://static.com

2. If your web API server and static file server are accessed using different sub-domains (webapi.example.com & static.example.com), you can go either with the above approach or set the domain while setting the cookie: Set-Cookie: name=value; domain=example.com Set-Cookie: name=value; domain=example.com

You may also consider reading this thread for CSRF