Los ataques CSRF (Cross-Site Request Forgery) siguen siendo una de las vulnerabilidades web más comunes y peligrosas. Aunque a simple vista pueden parecer complejos, entender cómo funcionan y cómo prevenirlos es esencial para cualquier desarrollador que trabaje con formularios, sesiones y autenticación.

En este artículo te explico qué es CSRF, cómo funciona y cómo proteger tus aplicaciones web de forma efectiva.

¿Qué es un ataque CSRF?

Un ataque CSRF ocurre cuando un atacante engaña al navegador de un usuario autenticado para que realice acciones no deseadas en una aplicación web en la que ya tiene sesión iniciada.

👉 El problema no es el usuario, sino que el navegador envía automáticamente las cookies de sesión, haciendo creer al servidor que la solicitud es legítima.

Ejemplo simple

1. El usuario inicia sesión en un sitio web legítimo.
2. Sin cerrar sesión, visita un sitio malicioso.
3. Ese sitio ejecuta una petición automática (formulario, imagen, script).
4. El servidor recibe la petición con la cookie válida.
5. La acción se ejecuta sin el consentimiento del usuario.

¿Por qué CSRF es tan peligroso?

Un ataque CSRF puede permitir:

• Cambiar contraseñas
• Modificar datos personales
• Realizar pagos o transferencias
• Publicar contenido sin autorización
• Eliminar cuentas o recursos

Todo esto sin que el usuario lo note.

Diferencia entre CSRF y XSS

Aunque suelen confundirse, son ataques distintos:

CSRF	XSS
Explota la confianza del servidor en el navegador	Explota la confianza del usuario en la aplicación
Usa cookies de sesión	Inyecta scripts maliciosos
No requiere inyección de código	Requiere entrada vulnerable

👉 Ambos deben protegerse, pero con técnicas diferentes.

Cómo protegerse contra CSRF

1. Tokens CSRF (la defensa principal)

Consiste en generar un token único, impredecible y por sesión o por formulario, que se envía junto con cada solicitud sensible.

Flujo básico:

1. El servidor genera un token CSRF.
2. Se envía al cliente (formulario o meta tag).
3. El cliente lo incluye en la solicitud.
4. El servidor valida el token antes de procesar la acción.

Si el token no existe o no coincide → la solicitud se rechaza.

2. Validar el método HTTP

• Evita acciones sensibles con GET
• Usa POST, PUT, DELETE para operaciones críticas

Los navegadores pueden ejecutar solicitudes GET sin interacción del usuario, lo que facilita ataques CSRF.

3. SameSite Cookies

Configurar cookies con el atributo:

SameSite=Strict

o

SameSite=Lax

Esto evita que las cookies de sesión se envíen en solicitudes cross-site.

👉 Es una capa adicional, no reemplaza el token CSRF.

4. Verificar el encabezado Origin o Referer

El servidor puede validar que la solicitud provenga del dominio esperado.

⚠️ No es una solución infalible, pero ayuda como refuerzo.

5. Autenticación por doble verificación

Para acciones críticas:

• Reingreso de contraseña
• Confirmación por correo
• 2FA

Reduce el impacto si un CSRF logra ejecutarse.

Ejemplo básico de protección CSRF en PHP

Generar el token

if (empty($_SESSION['csrf_token'])) {
  $_SESSION['csrf_token'] = bin2hex(random_bytes(32));
}

En el formulario

<input type="hidden" name="csrf_token" value="<?php echo $_SESSION['csrf_token']; ?>">

Validar el token

if (!hash_equals($_SESSION['csrf_token'], $_POST['csrf_token'])) {
  die('CSRF detectado');
}

¿Y en aplicaciones modernas (AJAX / JS)?

• Enviar el token en un header personalizado
• Leer el token desde un meta tag
• Validarlo en cada petición protegida

Ejemplo:

X-CSRF-TOKEN: abc123

Errores comunes al implementar CSRF

❌ Usar un token fijo
❌ No validar el token en el backend
❌ Proteger solo algunos formularios
❌ Confiar solo en JavaScript
❌ Pensar que HTTPS es suficiente

Buenas prácticas recomendadas

✔ Token único por sesión o petición
✔ Validación siempre del lado del servidor
✔ Usar frameworks con protección CSRF integrada
✔ Proteger todas las acciones que cambien estado
✔ Combinar varias capas de seguridad

Resumen del artículo

CSRF es una amenaza silenciosa pero extremadamente peligrosa. La buena noticia es que protegerse es sencillo si se hace correctamente.

Como desarrollador, implementar protección CSRF no es opcional:
es una responsabilidad básica de seguridad web.

Seguridad no es añadir parches después, es diseñar pensando en ataques desde el inicio.