(Spitballing: a standard way to implement CSRF protection with no cookies at all is when you generate the form you include a nonce. Then when the form is submitted you check whether it's a nonce you generated, which you do either by having stored it or generated it by hashing information you've stored. Implemented naively on a login form this would allow the attacker to fetch your page, extract the nonce, and include it in a cross-site request. But you could require it to be from the same IP. Alternatively I think you could fix this by having your login form set a custom header, which then browsers won't allow a cross-site POST for without a CORS preflight which you'd reject. But at this point I'm brainstorming and please don't take any of this very seriously!)
https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...
(It's also not clear to me that cookies are required, if there are other technically sound options that do this without setting cookies.)
This allows storing data such as the CRSF token value to check against the one in the hidden form element or X-CSRF-Token without inserting in a DB every time someone loads up a form.
That's how e.g Rails does it by default:
https://guides.rubyonrails.org/security.html#cross-site-requ...
https://api.rubyonrails.org/classes/ActionController/Request...
Note that to prevent session fixation, the session ought to be reset on a successful login (and logout), so it would require additional code to perform tracking across a successful login.
https://guides.rubyonrails.org/security.html#session-fixatio...
Session cookies are also used for Rails flash messages, commonly used to display errors in forms (including login forms), which often do HTTP redirects to GET routes in their non-GET controller actions.
https://api.rubyonrails.org/classes/ActionDispatch/Flash.htm...
https://api.rubyonrails.org/classes/ActionDispatch/Flash/Req...
https://stackoverflow.com/questions/24877244/rails-is-the-fl...
The underlying subtext is that these session cookies can be a necessity of securing the provided service, and thus can fall under valid "strictly necessary" usage, as long as they are not abused for tracking (by default nothing in the session cookie is stored nor logged anywhere)
