I'm thinking of login forms in particular:
By their nature, login forms block action on arbitrary input — without a valid username and password, you just get bounced. Is there a reason why these even need the addition of authenticity_token or similar cross-site request forgery protection at all?
I'm curious if login forms are one example where CSRF might even be generally undesirable:
Given an anonymous client, it should be allowed that the first point of contact with a site is to POST valid login credentials. CSRF prevents this direct interaction by first requiring that the client perform a GET to establish an anonymous session cookie, which is used as the basis for their authenticity_token. The token must then be posted back with the login credentials. The extra up-front step seems pointless when the actual goal here is to authenticate a user who arrives without a session and is trying to give their credentials.
Am I missing some security consideration in this scenario?
Without XSRF protection, an attacker could log the user into a malicious account, which they could use to track their activity. This is discussed in Robust Defenses for Cross-Site Request Forgery.
I don't see why the client should be able to POST login credentials as a first point of contact. For a web interface, in most practical cases the client has to GET the login page to retrieve the form.