Note: I have read the answer to this question, but found it unsatisfactory, probably because I don't understand enough about security.
Upon successful login, an httpOnly cookie is set by backend,
auth_token, and is sent back to the client's browser. This contains the authentication token. It will be sent automatically with each request (as is every cookie).
Another cookie is set by backend,
csrftoken, which is a long random string.
The frontend application (a JS framework) does NOT refer, store, or save
auth_tokenanywhere in its code.
The frontend application code checks to see if there's a
csrftokencookie present, and if there is, attaches it as a custom header,
X-CSRFToken, with the same value as
The server authenticates a user successfully if:
auth_tokenpresent and valid (database token)
X-CSRFTokenheader are present and not empty
Here's my question: What's the difference between having
csrftoken (and therefore the
X-CSRFToken header) as a very long, random string, and something like
1? It is clearly stated in multiple places that a CSRF attacker can't create custom headers..If the difference is "brute-forcing" the CSRF token, please explain what that would entail, and how the
X-CSRFToken header be set?