Protector CSRF

El Problema

Cross-site request forgery engana a usuarios autenticados para que envien peticiones maliciosas sin su conocimiento. La pagina de un atacante puede ejecutar una transferencia bancaria, cambiar una direccion de email o eliminar una cuenta — todo usando la cookie de sesion valida de la victima. Incluso SPAs modernas con tokens JWT pueden ser vulnerables si los tokens se almacenan en cookies sin atributos SameSite correctos o validacion de tokens CSRF.

El Prompt

Eres un ingeniero de seguridad web especializado en prevencion de CSRF. Analiza la proteccion CSRF de mi aplicacion e identifica brechas.

FRAMEWORK: [ej. Express, Django, Rails, Next.js, Laravel]
METODO DE AUTH: [ej. session cookies, JWT en cookies, JWT en localStorage]
ESTILO DE API: [ej. REST con formularios, REST con JSON, GraphQL]

CODIGO:
[pega middleware de auth, manejo de formularios, configuracion de cookies y endpoints que cambian estado]

Evaluar estas capas de defensa CSRF:
1. **Proteccion basada en tokens**: Tokens sincronizadores, double-submit cookies, double-submit firmado
2. **Atributo SameSite de cookies**: Strict, Lax o None — e implicaciones
3. **Validacion de Origin/Referer**: Verificar origen del request contra dominios permitidos
4. **Headers personalizados**: Requerir X-Requested-With o similar para requests AJAX
5. **Restricciones de Content-Type**: Rechazar content types no-JSON en endpoints de API

Para cada endpoint que cambia estado encontrado:
- Esta protegido contra CSRF? (Si/No/Parcial)
- Que escenario de ataque explotaria la brecha?
- Solucion recomendada con ejemplo de codigo

Proporcionar una implementacion completa de proteccion CSRF para mi framework especifico.

Ejemplo de Salida

## Analisis CSRF: 2 endpoints sin proteccion

### VULNERABLE: POST /api/account/email
No se requiere token CSRF. Cookie es SameSite=Lax pero el endpoint acepta datos form-encoded.
Ataque: Pagina del atacante envia un formulario oculto via POST, cambiando el email de la victima.
Solucion: Agregar middleware csurf y validar token en todas las rutas POST/PUT/DELETE.

### PROTEGIDO: POST /api/transfer (token validado)
Cookie SameSite=Strict + token CSRF en header X-CSRF-Token. Correctamente defendido.

Cuando Usar

Auditar protecciones CSRF al agregar nuevos endpoints que cambian estado, cambiar la estrategia de autenticacion o modificar configuraciones de cookies. Esencial durante revisiones de seguridad de flujos de checkout de e-commerce, paginas de gestion de cuenta y cualquier endpoint que modifique datos. Ejecutar despues de cambiar de formularios server-rendered a arquitectura SPA.

Tips Pro

• SameSite no es suficiente solo — SameSite=Lax todavia permite navegaciones GET de nivel superior, asi que protege endpoints GET que disparen efectos secundarios.
• Prueba con formularios cross-origin — crea una pagina HTML simple en un dominio diferente que envie formularios a tu API para verificar que la proteccion funciona.
• No olvides el logout — CSRF en endpoints de logout habilita ataques de login CSRF donde el atacante inicia sesion de la victima en la cuenta del atacante.
• GraphQL tambien necesita CSRF — endpoints de mutation sobre POST son igual de vulnerables que endpoints REST si las cookies llevan la autenticacion.