Please reflect that this is Signed Double Submit Cookie Pattern

[fetis]

You claim in the documentation that this package is for the Double Submit Cookie Pattern. Quote from the Readme

This module provides the necessary pieces required to implement CSRF protection using the Double Submit Cookie Pattern.

In reality, it implements only the Signed Double Submit Cookie Pattern, and it's impossible to use it for the Naive Double Submit Cookie Pattern.

Background
I needed to protect some forms that are used by unauthenticated users, but it's impossible to achieve because a session is required for the CSRF token generation. If you could explain to me how to configure the package for that goal, I would be happy, but atm I don't see the way.

[psibean]

You claim in the documentation that this package is for the Double Submit Cookie Pattern.
In reality, it implements only the Signed Double Submit Cookie Pattern, and it's impossible to use it for the Naive Double Submit Cookie Pattern.

You're absolutely right, this is true, that should be made more explicit.

However this shouldn't prevent you from using csrf-csrf for your use case.

a session is required for the CSRF token generation.

A session isn't required for csrf-csrf, what are you encountering that implies this? The getSessionIdentifier is a bit misleading - it doesn't have to return a session specifically. What it does need to return is just some random nuance, this nuance should be unique per user. If you're susceptible to CSRF attacks and need CSRF protection, then you should absolutely already have something that you can use here. For unauthenticated users, this typically means you have some way of identifying whether a request is made by the same user as some previous request, e.g. anonymous (unauthenticated) sessions, or some other identifier. If you don't have this, then why do you need CSRF protection at all? If you aren't using a httpOnly cookie to identify anonymous users, then your users aren't susceptible to CSRF attacks.

If you have _a httpOnly based cookie for detecting anonymous/unauthenticated users between requests, then that value is sufficient to be returned by getSessionIdentifier

[fetis]

e.g. anonymous (unauthenticated) sessions

We don't have any anonymous sessions in our application. CSRF means to protect only the login form from attacks, we don't use classical forms in the app besides the login

[psibean]

CSRF means to protect only the login form from attacks, we don't use classical forms in the app besides the login

If you don't have a cookie being used as an identifier, even if your login is using traditional forms, you won't need CSRF protection. If you don't have any httpOnly cookie element to identify anonymous users, then your users are not susceptible to CSRF attacks, even for login - traditional form or not.

we don't use classical forms in the app besides the login

So you're saying that your login form is dependent on the native browser form submit right? This alone does not make your users susceptible to CSRF attacks, this does not mean you need CSRF protection.

CSRF attacks typically require the presence of an identifying cookie (session or otherwise) , basic authentication is also vulnerable, but you shouldn't be using that nowadays.

With a session cookie (anonymous or authenticated), browsers automatically include that cookie with any / all requests sent to the domain the cookie belongs to. CSRF attacks are when an attacker tricks a users browser to make a request to the target server, the users credentials (the session cookie) will be included in any requests an attacker tricks a user into making.

Whilst sameSite: strict can be used as partial CSRF protection, it won't work for a traditional form submit as they do not perform CORs checks.

Recommendations

Whilst you aren't susceptible to CSRF attacks you might want to ensure that you check the Origin header is what you expect it to be to ensure login requests can only be made from your site. Additionally you may want to enforce strict CORs rules on your backend, ensuring that certain request types can only be received / processed if they come from your domain.