¿Qué hacer después de rechazar un token CSRF no válido?

Supongo que esto es para el "sincronizador" / un patrón, y no "doble envío de cookies" , desde tokens don Realmente no caducan en este último caso.

Puedes mitigar el problema haciendo que tus tokens CSRF tengan una vida más larga. Solo tenga un token por sesión (en lugar de por formulario), y haga que sea tan larga como la sesión. Entonces, si el token CSRF ha caducado, también lo ha hecho la sesión. Y luego la solicitud debe ser rechazada de todos modos.

Dicho esto, si por alguna razón obtienes una solicitud con una sesión válida pero con un token CSRF no válido, ¿qué deberías hacer? Como dices, el estado 403 es una buena elección. Para una API, podría responder con algún tipo de objeto o mensaje de error que explique al cliente qué fue lo que salió mal. O simplemente un cuerpo vacío, si es así como lidias con los errores.

Para envíos de formularios clásicos, es un poco más complicado. Si desea jugar realmente bien, debe responder con el formulario en el mismo estado en que el usuario intentó enviarlo, más un mensaje de error. Esto es un poco difícil de implementar, pero quizás ya tenga un sistema similar para otros errores.

Tenga en cuenta que puede devolver el nuevo token (como cookie, campo de formulario, o lo que sea) ya en la respuesta a la primera solicitud con el token caducado. No es necesario que el cliente realice otra solicitud solo para obtenerla.

En el equilibrio que se intenta lograr entre seguridad y facilidad de uso, hay muchos detalles contextuales que pesan fuerte o débilmente en una u otra dirección.

• ¿Cuáles son los riesgos de una solicitud falsificada y los beneficios relacionados para un atacante?
• qué tan plausible es un CSRF para su base de usuarios; de manera relacionada, ¿qué otras defensas están en su lugar (por ejemplo, eliminación de marcos, TLS forzado, CSP, etc.) contra tipos de ataques similares que el sitio y los usuarios puedan enfrentar?
• ¿Qué tan doloroso es para los usuarios someterse a la renovación de tokens o a la maquinaria de reenvío?

Etc. Así que realmente depende.

En general, una sesión de 30 días y un token de 12 horas se pesan mucho más en la dirección de la usabilidad. Entonces, debes confirmar que sea apropiado para tu contexto.

Suponiendo que, en un contexto orientado a la usabilidad, tener cualquier flujo de trabajo o condición de error que requiera que los usuarios hagan algo por segunda vez, será subóptimo. Por lo tanto, es una buena idea adoptar una solución que conserve las entradas del usuario en todos los casos si el token expira, o le informa que el token está a punto de caducar y debería renovarse, o cualquiera de las otras opciones.