TSecCSRF

Middleware to avoid Cross-site request forgery attacks. More info on CSRF at: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

This middleware is modeled after the double submit cookie pattern: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Double_Submit_Cookie

When a user authenticates, embedNew is used to send a random CSRF value as a cookie. (Alternatively, an authenticating service can be wrapped in withNewToken).

For requests that are unsafe (PUT, POST, DELETE, PATCH), services protected by the validated method in the middleware will check that the csrf token is present in both the header headerName and the cookie cookieName. Due to the Same-Origin policy, an attacker will be unable to reproduce this value in a custom header, resulting in a 401 Unauthorized response.

Requests with safe methods (such as GET, OPTIONS, HEAD) will have a new token embedded in them if there isn't one, or will receive a refreshed token based off of the previous token to mitigate the BREACH vulnerability. If a request contains an invalid token, regardless of whether it is a safe method, this middleware will fail it with 401 Unauthorized. In this situation, your user(s) should clear their cookies for your page, to receive a new token.

We'd like to emphasize that you please follow proper design principles in creating endpoints, as to not mutate in what should otherwise be idempotent methods (i.e no dropping your DB in a GET method, or altering user data). If you choose to not to, this middleware cannot protect you.