Description The Symfony form component provides a CSRF protection mechanism by using a random token injected in the form and using the session to store and control the token submitted by the user. When using the FrameworkBundle, this protection can be enabled or disabled with the configuration. If the configuration is not specified, by default, the mechanism is enabled as long as the session is enabled. In a recent change in the way the configuration is loaded, the default behavior has been dropped and, as a result, the CSRF protection is not enabled in form when not explicitly enabled, which makes the application sensible to CSRF attacks.
Resolution Symfony restored the default configuration to enable the CSRF protection by default. The patch for this issue is available here for branch 5.3.
Credits We would like to thank Catalin Dan and David Lochner for reporting the issue and Jérémy Derussé for fixing the issue.
Sponsor the Symfony project.Zaloguj się, aby dodać komentarz
Inne posty w tej grupie
Contributed by Hubert Lenoir in
SymfonyOnline June 2025 is almost here, starting in almost 2 months on:
June 10-11: Workshop days. It is possible to attend 1 two-day training or 2 one-day trainings. June 12-13: Online confe
Contributed by Kévin Dunglas in
SymfonyOnline June 2025 is almost here, starting in almost 2 months on:
June 10-11: Workshop days. It is possible to attend 1 two-day training or 2 one-day trainings. June 12-13: Online confe
This is the first article in a series showcasing the most important new features introduced by Symfony 7.3, which will be released at the end of May 2025.
This week, the upcoming Symfony 7.3 version improved the AsAlias attribute by adding a new argument, introduced Clock support for UriSigner, and refined the return type of the ContainerInterface::get(
SymfonyOnline June 2025 is almost here, starting in almost 2 months on:
June 10-11: Workshop days. It is possible to attend 1 two-day training or 2 one-day trainings. June 12-13: Online confe
