¿Qué es CSRF y cómo se protege una aplicación de solicitudes falsificadas?
Publicado el 2026-10-20 por frfrand
Ataques CSRF explicados con cookies, acciones involuntarias, tokens anti-CSRF, SameSite y defensas del servidor.
CSRF es un ataque que intenta aprovechar que el navegador de una persona autenticada puede enviar solicitudes a un sitio sin que esa persona haya querido realizar la acción. Significa Cross-Site Request Forgery, o falsificación de solicitudes entre sitios.
La clave está en que una web puede reconocer una sesión mediante cookies. Un atacante intenta provocar que el navegador envíe una operación aprovechando esa identidad.
El ejemplo de una orden que nunca diste
Imaginá que entrás a tu banco y dejás la sesión abierta. Después visitás una página desconocida que intenta provocar una solicitud para modificar algún dato de tu cuenta.
Si el banco aceptara la operación únicamente porque llegó con una cookie válida, podría tratar una acción no deseada como si la hubieras solicitado. Un diseño correcto comprueba algo más que «hay una sesión iniciada».
No significa que cualquier sitio pueda leer tus datos bancarios: la política de mismo origen limita muchas lecturas entre páginas. Impedir leer una respuesta y evitar que se envíe una solicitud son problemas diferentes.
¿Qué papel tienen las cookies?
El navegador puede adjuntar cookies a solicitudes según el dominio, las políticas de la cookie y el contexto de navegación. Esa comodidad permite mantener sesiones, pero también exige proteger acciones sensibles.
Atributos como SameSite ayudan a restringir cuándo se envían cookies entre sitios. Son una defensa útil, aunque no sustituyen todas las comprobaciones del servidor y requieren elegir una política adecuada al producto.
¿Qué es un token anti-CSRF?
Muchas aplicaciones generan un valor que el atacante no debería conocer y exigen que aparezca en las operaciones que modifican información. El servidor verifica que corresponda a la sesión o contexto esperado.
Frameworks como Django incluyen protecciones y mecanismos de verificación para formularios y solicitudes que cambian estado. Pero siguen dependiendo de una configuración correcta: desactivar protecciones para «hacer funcionar el frontend» puede crear un problema serio.
¿CORS resuelve CSRF?
No. CORS regula determinados accesos entre orígenes desde navegadores, pero no fue diseñado para sustituir una defensa anti-CSRF. Una solicitud puede producir efectos en el servidor incluso cuando el navegador no permite leer su respuesta.
Tampoco conviene confundir CSRF con XSS. En XSS el atacante consigue ejecutar código no confiable dentro del contexto de una página. Ambos problemas pueden relacionarse, pero sus causas y mitigaciones son diferentes.
¿Qué operaciones necesitan atención?
Cambiar una contraseña, modificar un correo, transferir fondos, agregar usuarios o eliminar registros son ejemplos de acciones cuyo origen legítimo debe verificarse.
Las solicitudes GET, por convención, no deberían modificar estado. Si visitar una URL desencadena un borrado, además del posible CSRF hay una decisión incorrecta de diseño HTTP.
¿Cómo comprobar la protección?
Probá que un formulario legítimo funciona y que una operación sin el token o contexto requerido se rechaza. Revisá también qué sucede cuando vence la sesión y cuando la petición proviene de un origen inesperado.
No hagas pruebas de seguridad contra servicios ajenos sin permiso. Un entorno de pruebas propio permite comprobar configuraciones sin poner en riesgo datos reales.
¿Qué significa esto en ArduMaker?
Si alojás en un VPS de ArduMaker una aplicación que usa cookies de sesión, su backend debe aplicar defensas CSRF adecuadas. El hecho de desplegarla bajo HTTPS no elimina automáticamente ese riesgo.
En resumen: CSRF intenta convertir la sesión de un usuario legítimo en una operación que no autorizó. La defensa requiere validar la intención de la solicitud, además de la identidad.
Fuentes: OWASP CSRF Prevention Cheat Sheet · Protección CSRF de Django.