¿Por qué los desarrolladores de aplicaciones web tienen que incluir tokens de falsificación de solicitudes entre sitios en sus formularios web?

Realmente no tienen que hacerlo, por ejemplo, en Django hay un middleware CSRF que los agrega automáticamente en todas partes y realiza las comprobaciones en cada envío.

La razón por la que los necesita es el modelo de seguridad del navegador web: se debe permitir que los sitios se envíen a otros sitios, por lo que cosas como los proveedores de inicio de sesión basados ​​en la nube (como Facebook) aún funcionan. Pero el problema es que cuando el envío se realiza a algún dominio, las cookies para ese dominio se incluyen automáticamente en los encabezados, por lo que si el usuario ya ha iniciado sesión en PayPal, la falta de protección CSRF permitiría que un sitio aleatorio emitiera una solicitud de pago. No es genial

TL; DR: encuentre un marco que proteja CSRF por usted. Este debería ser el estado predeterminado de las cosas, solo desactívelo cuando sepa por qué (por ejemplo, usted es el proveedor de inicio de sesión en la nube mencionado anteriormente o algo así).

Porque CSRF es un problema real. Los tokens de hash de formulario validados del lado del servidor son una forma de contrarrestarlo. No todos los formularios necesitan tokens de firma hash dependiendo de cuánto daño pueda hacer con él, pero si diseña un CMS es fácil aplicarlo a todos los formularios independientemente.

¿Quién dijo que lo hacen? Escribí solicitudes durante años y nunca lo hice. Enlaces reales entre sitios, claro, pero no fingir tonterías. (Y en el pasado, las personas no estaban tan preocupadas por los enlaces y virus entre sitios: los programadores estaban demasiado ocupados escribiendo programas reales, y los guiones no habían llegado al punto en que los niños de los guiones pudieran usarlos para causar daño).