CSRF Token for Anti Automation for multiple requests
Need some inputs for the CSRF token design to prevent anti-automation.
When a page loads for an user session, a request is given to the server, which would fetch the CSRF token , returned as part of the Get Response of Page Load.
The idea is to provide a solution, where no major state is stored on the server-except for one token for each user session per request.
Everytime a request is made (GET/POST), the existing token is validate and a new token is returned from the server to the client. This is stored in the user session.
On sending the POST request, client validates whether the token value is equal to value in the session and server validates, whether the token received in the request is same as the token stored in the session.
When the user performs an action, there can be multiple requests to the server at a point of time from the client side. Or before the earlier request's response is received, there can be another request send from the client application.
In this case , would the same CSRF token be send? Or should a pool of tokens be returned from the server for the same?
Can this token's also be used for GET requests so as to prevent the attacker to not clog the server with replay attacks with the GET requests?
Also, should the CSRF token send in the header or body?
Is there any need for it to be encrypted?
