Express.js
Explica cómo CSRF explota credenciales enviadas automáticamente y cómo combinar SameSite, tokens, Origin y métodos seguros en aplicaciones Express.js.
CSRF aprovecha credenciales que el navegador adjunta automáticamente para hacer que una víctima autenticada ejecute una acción desde otro sitio.
El ataque no necesita leer la cookie. Solo necesita que el navegador la envíe junto a una request preparada por el atacante.
víctima autenticada en bank.example
↓ visita evil.example
evil.example dispara POST
↓ navegador añade cookie de bank.example
servidor ejecuta acción como la víctimaCSRF afecta principalmente autenticación basada en cookies u otras credenciales automáticas.
Normalmente requiere:
Bloquea cookies en muchos contextos cross-site. Reduce CSRF, pero puede romper enlaces externos y flujos OAuth.
Bloquea buena parte de mutations cross-site, pero permite algunos top-level navigations seguras. Es un buen default frecuente, no una garantía total.
Permite envío cross-site y exige Secure. Requiere controles CSRF explícitos.
SameSite se basa en “site”, no exactamente “origin”. Subdominios y esquemas pueden introducir matices.
El servidor genera un token asociado a la session:
session store
→ csrfSecret/token
→ formulario o endpoint bootstrap
→ cliente lo devuelve en header/bodyEl atacante no puede leerlo por same-origin policy.
router.post('/orders', requireCsrfToken, createOrderHandler);El token debe compararse de forma segura y no aparecer en URLs o logs.
El servidor envía una cookie legible por JavaScript y el cliente repite el valor en un header. El servidor comprueba igualdad, idealmente con token firmado o ligado a session.
Una implementación ingenua puede ser vulnerable a cookie injection desde subdominios. Prefijos host-only y firma mejoran el diseño.
Para mutations, valida:
const origin = request.get('origin');
if (origin !== 'https://app.example.com') {
throw new InvalidCsrfOriginError();
}Origin suele estar presente en requests CORS y POST modernos. Referer puede servir como fallback, pero tiene políticas de privacidad. Una ausencia no debe aceptarse automáticamente sin analizar clientes.
Una SPA puede enviar X-CSRF-Token. Un sitio externo no puede añadirlo en una request simple sin preflight. Esto ayuda cuando CORS solo permite origins confiables.
No dependas únicamente de “JSON no es simple”; una mala configuración CORS puede autorizar al atacante.
GET y HEAD no deben cambiar estado. Un enlace o imagen puede disparar GET cross-site sin preflight.
Incorrecto:
GET /orders/123/cancelCorrecto:
POST /orders/123/cancelcon CSRF y autorización.
Un JWT almacenado en cookie sigue enviándose automáticamente y sigue sujeto a CSRF. El formato del valor no cambia la amenaza.
Un bearer token en Authorization añadido explícitamente por JavaScript reduce CSRF clásico, pero si está accesible al script aumenta impacto de XSS.
Un atacante puede hacer que la víctima inicie sesión en la cuenta del atacante, provocando que cargue información sensible allí. Protege login y linking de cuentas, no solo operaciones posteriores.
Puede parecer menor, pero facilita molestias o encadenamiento de ataques. Usa POST y verificación apropiada.
const requireCsrf: RequestHandler = (request, response, next) => {
if (['GET', 'HEAD', 'OPTIONS'].includes(request.method)) {
next();
return;
}
const expected = request.session.csrfToken;
const received = request.get('x-csrf-token');
const origin = request.get('origin');
if (
origin !== config.frontendOrigin ||
!expected ||
!received ||
!timingSafeEqual(expected, received)
) {
response.status(403).json({ code: 'CSRF_VALIDATION_FAILED' });
return;
}
next();
};En producción, utiliza una implementación revisada y maneja buffers/longitudes correctamente.
El token puede ser:
Tokens por request ofrecen protección adicional, pero complican back/forward y múltiples tabs. Un token aleatorio por session suele ser suficiente para muchas aplicaciones.
SameSite=None puede ser necesario; combina credentials CORS, token y Origin validation.
No están sujetas a browser CSRF del mismo modo. Pueden usar bearer credentials y otros controles.
No usan session del navegador. Verifica firma del proveedor, no CSRF token.
Puede compartir site o establecer cookies según Domain. Host-only cookies y aislamiento de dominios importan.
Un atacante puede enviar formularios application/x-www-form-urlencoded sin CORS preflight. No asumas que solo aceptas JSON si el parser o proxy tolera otros formatos.
Las pruebas HTTP unitarias no sustituyen una prueba en navegador para atributos de cookies.
Tokens por session son prácticos; tokens por request son más estrictos pero complican UX. SameSite reduce necesidad, pero arquitecturas cross-site requieren defensa adicional. Origin validation es simple, aunque debe contemplar clientes legítimos.
XSS y salida segura explica cómo contenido no confiable puede convertirse en código en el navegador y por qué el backend también participa en la defensa.