To disable sessions in form contexts one should use the form config instead.

Now I'm realizing that there is no mention to that config anywhere in the docs (https://github.com/symfony/symfony/blob/4.4/src/Symfony/Bundle/FrameworkBundle/DependencyInjection/Configuration.php#L163).

What I tried to add was just a "reverse" link for what is said on https://symfony.com/doc/current/security/csrf.html:

That's why a session is started automatically as soon as you render a form with CSRF protection.

So in which file is form config happening? Or do you mean csrf_protection in framework config?: https://symfony.com/doc/current/reference/configuration/framework.html#csrf-protection

There are two available config for csrf, the one you referring to, enabling it globally at the framework level:

// config/packages/framework.yaml
framework:
    csrf_protection: true/false

And the one I'm referring to (which does not seem documented and that I linked above), to enable it at the form level only:

// config/packages/form.yaml
framework:
    form:
        csrf_protection: true/false

(https://github.com/symfony/symfony/blob/4.4/src/Symfony/Bundle/FrameworkBundle/DependencyInjection/Configuration.php#L169)

Sorry, I don't fully understand the source code :-(
The best page to document this would probably be https://symfony.com/doc/current/forms.html - since it's probably not worth an own page?!
But some other questions first:
What happens if csrf_protection is true in one, and false in the other file?
What else can be configured in form.yaml?
What's the purpose of form.yaml at all? Is there any advantage over doing it in framework.yaml? Both ways are for users of the full framework only, right?

What happens if csrf_protection is true in one, and false in the other file?

framework.csrf_protection defines the default value of framework.form.csrf_protection (see the comment in the link from my previous comment).

So defining the global as true defines the form protection as true, then switching the form one to false would be my approach in the current PR context.

In the other hand, defining the global as false would make the form protection disabled, then trying to enable it at the form level wouldn't work as expected (however I have not tested if it throws a clear exception or if it just fails silently).

What else can be configured in form.yaml?

The best documentation is your console ;), using:

bin/console config:dump framework
# or
bin/console config:dump framework form
bin/console config:dump framework csrf_protection

What's the purpose of form.yaml at all?

Same as mailer.yaml or any other component configured by the FrameworkBundle (i.e serializer, messenger, lock, ...) to avoid having hundred of lines in framework.yaml.
But feel free to decide to add this file or not by inlining this config directly in framework.yaml :).

Both ways are for users of the full framework only, right?

Right :)

Unable to find node at path "framework.csrf".

Sorry it's bin/console config:dump framework csrf_protection 🤦 (I've edited my comment).

In the other hand, defining the global as false would make the form protection disabled, then trying to enable it at the form level wouldn't work as expected (however I have not tested if it throws a clear exception or if it just fails silently).

So, I've just tested:

# config/packages/framework.yaml
framework:
    csrf_protection: false
    form:
        csrf_protection: true

and I got the following:

The service "form.type_extension.csrf" has a dependency on a non-existent service "security.csrf.token_manager".

I've opened symfony/symfony#46960 to try to improve this.

OK, but still: If you do it the other way around:

# config/packages/framework.yaml
framework:
    csrf_protection: true
    form:
        csrf_protection: false

... where will CSRF be enabled then?

The framework is using the global config to wire services symfony/security-csrf component, they can be used elsewhere, not only forms, and can rely on other implementations not using a session (i.e. a specific cookie).

Sorry, I don't have a clear enough picture to suggest something. Maybe somebody else has an idea - ping @javiereguiluz