What if I opened two browser tabs, Tab A and Tab B (two separate forms)? I submit the form on Tab A, now when I go to submit form B I get a CSRF validation error. I feel like UX might suffer if this was implemented as a global change.

form submission doesnt invalidate the token. the same token per form and session is used, but it would suffice to use only one token for any form per session.

a small proposal on how this can be achieved:

• add a security.csrf.default_token_id config variable to the security bundle's config (with a default value of default or symfony or app or ...)
• inject this into the token factory. this token id is used, when a null is passed as the id on any factory method.
• change the csrf_token_id (and intention for 2.x) option's default value to null

OWASP says that per request tokens are the most secure: https://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet

To further enhance the security of this proposed design, consider randomizing the CSRF token parameter name and or value for each request.

well they also mention the caveats after your quoted part. but symfony doesnt use per-request tokens, but per-form tokens.
maybe we should consider using https://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet#Double_Submit_Cookies as a default csrf protection strategy in symfony, this seems like the most eloquent solution to me

@backbone87 Sounds like an elegant and simple solution to me. You'd need to use two different CSRF tokens though: one for HTTP requests (stored in normal cookie - could be sniffed by MITM) and one for HTTPS requests (stored in a HTTPS-only cookie - not sniffable).

I think it should be possible to implement this as new implementation of CsrfTokenManagerInterface which ignores the $tokenId and uses RequestStack internally to check the current scheme and set the cookies. Do you want to work on it? :)

i have created a new ticket for the double submit cookies, as the issue here deals with another problem not directly related to the security-csrf component, but the application of the component within the form csrf extension.

since the DSC feature can only be merged into symfony 3 (?), it would be nice to have a fix for this issue, that could be merged into symfony 2

the problem is in the following line:
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Form/Extension/Csrf/Type/FormTypeCsrfExtension.php#L78

Would a change to $options['csrf_token_id'] ?: 'default' suffice?
or actually more acurate: $options['csrf_token_id'] === null ? (string) $options['csrf_token_id'] : 'default' (any string is accepted by https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Security/Csrf/CsrfTokenManagerInterface.php#L30 ) and the CsrfFormExtension allows mixed for csrf_token_id option.

@backbone87 Using the same token would pose a security threat in mixed HTTP/HTTPS environments. It's easy to sniff the CSRF token of a HTTP form. The attacker would consequently be able to use the same token for a HTTPS form.

At the moment, the number of tokens in the session is limited by the number of forms you have, so this functionality does not bear the potential to bring down the server. If you have too many forms in your application and want to reduce the size of your session, I suggest to use custom IDs or type extension - but take care of the HTTP/HTTPS attack vector described above.

Once we implement DSC, the CSRF token ID becomes obsolete anyway. I don't think there's anything we should do here.

that reasoning is weird. we dont use different token IDs based on protocol currently, but based on form name/type name. if i use the same form, one on https and one on http, you have the same security issue.

@backbone87 has a valid point IMO.

Since #24992 different protocols do not share the same tokens anymore. So I think we can close here as using the same token ID for all forms can easily be done in a custom extension if really needed.