Skip to content

[Form] CSRF form field still added automatically, despite stateless CSRF #60536

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ThomasLandauer opened this issue May 25, 2025 · 5 comments
Closed

Comments

@ThomasLandauer
Copy link
Contributor

Symfony version(s) affected

7.2.6

Description

Since Symfony 7.2, CSRF protection is enabled statelessly by default, see https://github.com/symfony/recipes/blob/main/symfony/form/7.2/config/packages/csrf.yaml
(If I got that wrong, then symfony/symfony-docs#20994 would be obsolete)

However, with the default settings, I'm still getting a CSRF token field rendered, with the confusing value of csrf-token:

<input type="hidden" id="form__token" name="form[_token]" data-controller="csrf-protection" novalidate="novalidate" value="csrf-token">

How to reproduce

See above

Possible Solution

No response

Additional Context

No response

@nicolas-grekas
Copy link
Member

nicolas-grekas commented May 25, 2025

That's precisely how this works: rendering the field allows the JS side (when enabled) to have a field to hook on.

@nicolas-grekas nicolas-grekas closed this as not planned Won't fix, can't repro, duplicate, stale May 25, 2025
@ThomasLandauer
Copy link
Contributor Author

OK, I see. But wouldn't it be better to introduce a Symfony option if this field should be rendered?
And/or changing its value to something like csrf-token-will-be-generated-by-javascript to give people a clue?

@nicolas-grekas
Copy link
Member

I don't think that's a good idea: with the current implementation, the field is also needed on the server-side, to trigger the corresponding code path. In theory, we could likely remove this need, but that's likely going to be a significant change. Also, adding an option = adding complexity. 2 reasons that make me think we shouldn't do this.

@ThomasLandauer
Copy link
Contributor Author

OK. But what about changing the value to something more descriptive? Is anything relying on that very string?

@nicolas-grekas
Copy link
Member

The JS side yes: this gives the name of the header/cookie to use.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants