Anti-CSRF tokens were introduced in #503 as a security measure (and as part of upgrading to a more recent version of Spring). At the time, I went with the default behavior and applied it evenly to all non-GET requests.
The login page has a slightly different UX and threat profile than the rest of the forms, though. In particular, with most forms, the anti-CSRF token's expiration time is equal to or greater than the login session timeout, so that you are logged out for inactivity before a page's token expires. The login page, on the other hand, should be able to be loaded, wait for a long time, and then successfully log in, rather than face an expired token error.
A common technique to protect the log in form is by using a JavaScript function to obtain a valid CSRF token before the form submission. By doing this, there is no need to think about session timeouts ... because the session is created right before the form submission ..., so the user can stay on the login page and submit the username/password when he wants.
Apply this technique, or one like it, to the login page, so as to prevent stale CSRF token errors on login.
kfogel
commented
6 years ago
Anti-CSRF tokens were introduced in #503 as a security measure (and as part of upgrading to a more recent version of Spring). At the time, I went with the default behavior and applied it evenly to all non-
GETrequests.The login page has a slightly different UX and threat profile than the rest of the forms, though. In particular, with most forms, the anti-CSRF token's expiration time is equal to or greater than the login session timeout, so that you are logged out for inactivity before a page's token expires. The login page, on the other hand, should be able to be loaded, wait for a long time, and then successfully log in, rather than face an expired token error.
The Spring docs specifically call this out:
Apply this technique, or one like it, to the login page, so as to prevent stale CSRF token errors on login.
Found by @kfogel during a demo.