Cuando una aplicación rechaza una acción con un error CSRF, normalmente no significa que la cuenta esté bloqueada ni que el servidor se haya caído. Suele indicar que la petición no incluye una prueba válida de que procede de la sesión legítima, algo esencial para evitar cambios de contraseña, transferencias o envíos de formularios manipulados. Aquí explico qué lo provoca, cómo diagnosticarlo y qué medidas funcionan de verdad desde la perspectiva del desarrollo seguro y el hacking ético.
La protección CSRF valida que cada acción sensible sea legítima
- Causa habitual: falta el token, ha caducado o no coincide con la sesión.
- Primer paso: revisar la petición fallida en las herramientas de desarrollo del navegador.
- Defensa principal: usar tokens CSRF sincronizados o un patrón de cookie firmado y validado.
- Refuerzo útil: configurar SameSite y validar los encabezados Origin o Referer cuando proceda.
- Error frecuente: confiar solo en CORS, CAPTCHA o cookies HttpOnly.
Qué significa un error CSRF y por qué aparece
CSRF significa Cross-Site Request Forgery, o falsificación de peticiones entre sitios. El ataque intenta aprovechar que el navegador envía automáticamente la cookie de sesión cuando una persona autenticada visita otra página. El servidor recibe la petición con credenciales válidas, aunque el usuario no haya querido realizar esa acción.
La aplicación evita este escenario mediante un token CSRF, una cadena impredecible vinculada a la sesión o a la petición. Si el servidor espera ese valor y no lo encuentra, recibe uno antiguo o detecta que no coincide, bloquea la operación y muestra el error.
Un ejemplo sencillo
Imaginemos una tienda online con una sesión activa. Mientras el usuario navega por otra web, esa página intenta enviar una petición para cambiar la dirección de entrega. La cookie puede viajar automáticamente, pero la página maliciosa no debería conocer el token secreto del formulario. Si la tienda lo valida correctamente, la operación se detiene.
CSRF no es lo mismo que XSS. En un ataque XSS se inyecta código que se ejecuta dentro del sitio legítimo; en CSRF se intenta hacer que el navegador envíe una petición no deseada. Esta diferencia importa porque un token CSRF no corrige una vulnerabilidad XSS, y una aplicación puede necesitar ambas defensas.
Las causas más habituales del fallo
En mis revisiones de aplicaciones, el problema rara vez está en el concepto de CSRF. Lo más común es una integración incompleta entre frontend, backend, cookies y proxy. La siguiente tabla ayuda a localizar el origen sin empezar a cambiar configuraciones al azar.
| Causa | Qué suele verse | Corrección habitual |
|---|---|---|
| Token ausente | La petición POST, PUT, PATCH o DELETE no contiene el valor exigido. | Incluirlo en un campo oculto o en un encabezado específico. |
| Token caducado | El formulario permaneció abierto demasiado tiempo. | Regenerar el formulario y gestionar sesiones expiradas de forma clara. |
| Token desincronizado | El frontend conserva un valor distinto al que espera el servidor. | Revisar caché, renovación de sesión y llamadas asíncronas. |
| Cookie no enviada | La sesión desaparece o el servidor cree que el usuario no está autenticado. | Comprobar dominio, ruta, HTTPS, credenciales y atributo SameSite. |
| Petición AJAX incompleta | Los formularios funcionan, pero la interfaz JavaScript falla. | Enviar el token también en las peticiones fetch o XMLHttpRequest. |
| Proxy o caché mal configurado | Algunos usuarios reciben tokens repetidos o páginas antiguas. | Excluir formularios personalizados de cachés compartidas. |
También puede aparecer después de cambiar de HTTP a HTTPS, modificar el dominio, activar un CDN o separar la API del frontend. En esos casos, el fallo no siempre está en el token, sino en la relación entre origen, cookies y credenciales.
Cómo diagnosticarlo sin perder tiempo
Para una persona usuaria, lo primero es recargar la página, cerrar la sesión y volver a entrar. Si el aviso continúa, conviene borrar las cookies del sitio o probar una ventana privada. Esto puede resolver un token obsoleto, pero no arregla un defecto de configuración del servidor.
Para quien administra o desarrolla la aplicación, la forma más rápida consiste en inspeccionar la petición fallida en las herramientas del navegador. Hay que comparar una petición que funciona con otra que produce el error y revisar estos elementos:
- Método HTTP. Las operaciones que cambian datos no deberían aceptar peticiones sin protección.
- Cookie de sesión. Hay que confirmar que se envía al dominio, ruta y protocolo correctos.
- Token. Debe aparecer en el campo del formulario o en el encabezado previsto, con el nombre exacto.
- Origen de la petición. Origin y Referer pueden revelar una llamada que llega desde un contexto inesperado.
- Respuesta del servidor. El código HTTP y los registros suelen indicar si falla la ausencia, la caducidad o la validación del token.
No recomiendo desactivar temporalmente la validación para “confirmar” el diagnóstico en producción. Es más seguro reproducir el caso en un entorno de pruebas y registrar únicamente datos técnicos, nunca tokens, cookies o credenciales reales.
Qué comprobar en una SPA
En una aplicación de una sola página, el HTML inicial puede cargar correctamente y fallar solo al guardar cambios. El motivo suele ser que el código JavaScript envía la sesión, pero olvida añadir el token al encabezado o no usa la opción de credenciales adecuada. La prueba debe cubrir login, carga del token, renovación de sesión y cada método que modifica datos.
Cómo corregir la protección según la arquitectura
En formularios tradicionales, el patrón más sencillo es generar un token en el servidor, insertarlo en el formulario y validarlo al recibir la petición. El valor debe ser impredecible, estar ligado a la sesión y no reutilizarse como contraseña ni como identificador visible del usuario.
En una API consumida por JavaScript, el token puede viajar en un encabezado como X-CSRF-Token. La implementación concreta depende del framework, pero la regla es la misma: el servidor debe validar el token antes de ejecutar la acción, no después de guardar los cambios.
Otra alternativa es el patrón de doble cookie. El servidor envía una cookie con el token y el cliente copia ese valor en un encabezado. El backend compara ambos elementos. Si se utiliza esta técnica, la cookie debe estar protegida contra modificaciones y la aplicación debe entender que leer una cookie desde JavaScript no equivale a validarla.
Cookies SameSite como capa adicional
El atributo SameSite limita cuándo el navegador envía cookies en peticiones iniciadas desde otro sitio. Lax suele ofrecer un equilibrio razonable para muchas aplicaciones, mientras que Strict aplica una política más rígida y puede afectar ciertos flujos de navegación o integraciones externas.
SameSite ayuda, pero no debe convertirse en la única defensa. Hay escenarios con subdominios, aplicaciones móviles, navegadores antiguos o integraciones legítimas entre dominios donde la política no cubre todo el riesgo. OWASP recomienda combinar el token con controles adicionales en las operaciones sensibles.
Lee también: Ataque Homográfico - ¿Cómo detectar y prevenir el engaño?
Validación del origen
Comprobar los encabezados Origin o Referer puede reforzar la protección, sobre todo en APIs y paneles administrativos. No conviene tratar un Referer ausente como prueba automática de ataque, porque algunos navegadores, extensiones y políticas de privacidad lo eliminan. La aplicación debe definir una estrategia clara para esos casos.
Qué soluciones no bastan por sí solas
Uno de los errores más repetidos consiste en pensar que una sola cabecera de seguridad resuelve CSRF. CORS no impide todas las peticiones no deseadas; controla qué respuestas puede leer un origen, pero no sustituye la validación de una intención legítima en el servidor.
| Medida | Qué aporta | Por qué no es suficiente sola |
|---|---|---|
| Token CSRF | Demuestra que la petición incluye un valor esperado por la aplicación. | Debe estar bien integrado y protegido frente a XSS. |
| SameSite | Reduce el envío de cookies en determinados contextos cross-site. | Puede no cubrir todos los flujos ni todas las arquitecturas. |
| HttpOnly | Dificulta que JavaScript lea la cookie de sesión. | No evita que el navegador envíe automáticamente esa cookie. |
| CORS | Controla el acceso de scripts de otros orígenes a las respuestas. | No reemplaza un mecanismo anti-CSRF. |
| CAPTCHA | Reduce ciertos abusos automatizados. | No valida el origen legítimo de cada petición. |
Tampoco conviene aceptar acciones que cambian datos mediante GET. Una petición de lectura puede activarse con más facilidad desde una imagen, un enlace o una redirección. Usar POST, PUT, PATCH o DELETE para modificar información no elimina CSRF, pero reduce superficies de ataque innecesarias.
Cómo revisar el problema desde el hacking ético
Una auditoría autorizada debe empezar por identificar qué acciones tienen impacto real. Cambiar el correo, modificar permisos, crear usuarios, eliminar registros o iniciar operaciones financieras merecen una revisión prioritaria. La prueba debe realizarse con cuentas de laboratorio y sin enviar peticiones contra sistemas ajenos.
El objetivo no es demostrar que una petición puede enviarse, sino comprobar si el servidor la acepta sin un token válido y sin un origen permitido. También hay que probar tokens ausentes, modificados, reutilizados, asociados a otra sesión y enviados después de cerrar sesión.
- Confirmar que las operaciones de solo lectura no se confunden con acciones de cambio.
- Verificar que cada formulario sensible genera y valida su propio mecanismo de protección.
- Comprobar que las respuestas de error no revelan tokens ni información de sesión.
- Revisar que la protección funciona igual en navegador, aplicación móvil y API.
- Registrar la corrección y repetir las pruebas después de cada cambio de autenticación o dominio.
En una revisión profesional, el error CSRF es una señal útil: demuestra que la aplicación está rechazando una petición, pero no garantiza que todas las rutas estén protegidas. La cobertura real se obtiene revisando el mapa completo de acciones y no solo el formulario donde apareció el aviso.
La señal que conviene conservar después de corregirlo
Una solución sólida combina tokens validados en el servidor, cookies configuradas con criterio, controles de origen y pruebas sobre todas las operaciones que modifican datos. Si el fallo solo desaparece al borrar cookies o desactivar una comprobación, el problema sigue presente.
Mi recomendación es conservar una prueba automatizada que intente ejecutar cada acción sensible sin token, con un token alterado y con una sesión diferente. Así, una futura actualización del frontend, del framework o del proxy no convierte una protección aparentemente correcta en una puerta abierta.
