The list of CSRF token ids that will use stateless CSRF protection.

This option was added in Symfony 7.2 to aid in configuring stateless CSRF protection.

Whether to check the CSRF token in a header in addition to a cookie when using stateless protection.

Can be set to ``2`` (the value of the ``CHECK_ONLY_HEADER`` constant on the

:class:`Symfony\\Component\\Security\\Csrf\\SameOriginCsrfTokenManager` class) to check only the header

and not the cookie.

This option was added in Symfony 7.2 to aid in configuring stateless CSRF protection.

The name of the cookie (and header) to use for the double-submit when using stateless protection.

This option was added in Symfony 7.2 to aid in configuring stateless CSRF protection.

This is the HTML attributes that should be added to the CSRF token field of your forms.

This is the CSRF token id that should be used for validating the CSRF tokens of your forms.

Note that this setting applies only to autoconfigured form types, which usually means only

to your own form types and not to form types registered by third-party bundles.

Anti-CSRF tokens can be managed either in a stateful way: they're put in the

session and are unique for each user and for each kind of action, or in a

stateless way: they're generated on the client-side.

stateless CSRF tokens, see below.

Stateless CSRF tokens use a CSRF protection that doesn't need the session. This

means that you can cache the entire page and still have CSRF protection.

When a stateless CSRF token is checked for validity, Symfony verifies the

``Origin`` and the ``Referer`` headers of the incoming HTTP request.

If either of these headers match the target origin of the application (its domain

name), the CSRF token is considered valid. This relies on the app being able to

know its own target origin. Don't miss configuring your reverse proxy if you're

behind one. See :doc:`/deployment/proxies`.

While stateful CSRF tokens are better seggregated per form or action, stateless

ones don't need many token identifiers. In the previous example, ``authenticate``

and ``logout`` are listed because they're the default identifiers used by the

Symfony Security component. The ``submit`` identifier is then listed so that

form types defined by the application can use it by default. The following

configuration - which applies only to form types declared using autofiguration

(the default way to declare *your* services) - will make your form types use the

``submit`` token identifier by default:

In addition to the ``Origin`` and ``Referer`` headers, stateless CSRF protection

also checks a cookie and a header (named ``csrf-token`` by default, see the

:ref:`CSRF configuration reference <reference-framework-csrf-protection>`).

These extra checks are part of defense-in-depth strategies provided by the

stateless CSRF protection. They are optional and they require

`some JavaScript`_ to be activated. This JavaScript is responsible for generating

a crypto-safe random token when a form is submitted, then putting the token in

the hidden CSRF field of the form and submitting it also as a cookie and header.

On the server-side, the CSRF token is validated by checking the cookie and header

values. This "double-submit" protection relies on the same-origin policy

implemented by browsers and is strengthened by regenerating the token at every

form submission - which prevents cookie fixation issues - and by using

``samesite=strict`` and ``__Host-`` cookies, which make them domain-bound and

HTTPS-only.

Note that the default snippet of JavaScript provided by Symfony requires that

the hidden CSRF form field is either named ``_csrf_token``, or that it has the

``data-controller="csrf-protection"`` attribute. You can of course take

inspiration from this snippet to write your own, provided you follow the same

protocol.

As a last measure, a behavioral check is added on the server-side to ensure that

the validation method cannot be downgraded: if and only if a session is already

available, successful "double-submit" is remembered and is then required for

subsequent requests. This prevents attackers from exploiting potentially reduced

validation checks once cookie and/or header validation has been confirmed as

effective (they're optional by default as explained above).

Enforcing successful "double-submit" for every requests is not recommended as

as it could lead to a broken user experience. The opportunistic approach

described above is preferred because it allows the application to gracefully

degrade to ``Origin`` / ``Referer`` checks when JavaScript is not available.