Esto es lo que recibirás.

El endpoint /api/facturas/:id no valida que el usuario autenticado tenga permiso para acceder al recurso solicitado. Cualquier usuario con sesión iniciada puede acceder a las facturas de otros clientes simplemente cambiando el ID en la URL.

Un atacante autenticado podría descargar todas las facturas históricas del sistema, incluyendo datos personales (nombre, dirección, NIF), información de pago e historial de compras. Esto supone un riesgo grave de exposición de datos personales bajo el RGPD y podría resultar en sanciones regulatorias además del daño reputacional.

1. Iniciar sesión como usuario A (cliente legítimo)
2. Acceder a una factura propia: GET /api/facturas/12345
3. Modificar el ID en la URL: GET /api/facturas/12346
4. La respuesta devuelve la factura del cliente B sin error de autorización

Implementar comprobación de propiedad en el endpoint: validar que el user_id del usuario autenticado coincide con el user_id asociado a la factura solicitada antes de devolver los datos. Aplicar el mismo patrón a todos los endpoints que reciben IDs de recursos en la URL.

El campo "mensaje" del formulario de soporte no escapa correctamente el HTML enviado por el usuario. Un atacante puede inyectar código JavaScript que se ejecuta cuando un agente de soporte abre el ticket en el panel de administración.

Un atacante puede secuestrar la sesión de un agente de soporte, robando cookies de autenticación y obteniendo acceso al panel de administración. En el peor escenario, esto podría escalar a control completo del sistema y de los datos de todos los clientes.

1. Crear un ticket de soporte con el mensaje: '<script>alert(document.cookie)</script>'
2. El agente de soporte abre el ticket en el panel de administración
3. El JavaScript se ejecuta en el contexto del agente, exponiendo sus cookies de sesión

Escapar todos los outputs de usuario en el HTML del panel de administración. Usar una librería de sanitización como DOMPurify o aplicar codificación HTML estándar al renderizar texto del usuario. Establecer una Content-Security-Policy estricta como defensa adicional.

Los tokens JWT generados por el endpoint /api/auth/login no incluyen el claim "exp" (expiration). Los tokens son válidos indefinidamente una vez emitidos, sin posibilidad de invalidación individual.

Si un token es comprometido (mediante phishing, malware en el dispositivo del usuario, etc.), el atacante mantiene acceso al sistema permanentemente. No hay forma de invalidar el token sin rotar la clave de firma del JWT, lo cual cerraría sesión a todos los usuarios simultáneamente.

1. Hacer login a través de POST /api/auth/login
2. Capturar el token JWT en la respuesta
3. Decodificar el token (jwt.io)
4. Confirmar que falta el campo "exp"
5. Usar el token 30 días después: sigue siendo válido

Añadir un claim "exp" con un tiempo de vida razonable (15-60 minutos para tokens de acceso). Implementar un sistema de refresh tokens para sesiones de larga duración. Establecer una rotación periódica de la clave de firma del JWT.

El servidor web no devuelve cabeceras de seguridad importantes en las respuestas HTTP: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options y Referrer-Policy. Estas cabeceras son la primera línea de defensa contra varios tipos de ataques cliente.

Aumenta el riesgo de ataques de clickjacking, XSS, downgrade a HTTP y filtración de información mediante el referrer. No son ataques directos pero reducen las defensas en profundidad y dejan al usuario expuesto a vectores de ataque que podrían mitigarse fácilmente.

1. Acceder a https://ejemplo.com con curl
2. Inspeccionar las cabeceras de respuesta: curl -I https://ejemplo.com
3. Verificar la ausencia de las cabeceras mencionadas

Configurar el servidor web (nginx/apache) o el proxy/CDN (Cloudflare, Vercel) para enviar las cabeceras de seguridad recomendadas. Validar la configuración usando securityheaders.com.