Això és el que rebràs.

L'endpoint /api/facturas/:id no valida que l'usuari autenticat tingui permís per accedir al recurs sol·licitat. Qualsevol usuari amb sessió iniciada pot accedir a les factures d'altres clients simplement canviant l'ID a la URL.

Un atacant autenticat podria descarregar totes les factures històriques del sistema, incloent-hi dades personals (nom, adreça, NIF), informació de pagament i historial de compres. Això suposa un risc greu d'exposició de dades personals sota el RGPD i podria comportar sancions regulatòries a més del dany reputacional.

1. Iniciar sessió com a usuari A (client legítim)
2. Accedir a una factura pròpia: GET /api/facturas/12345
3. Modificar l'ID a la URL: GET /api/facturas/12346
4. La resposta retorna la factura del client B sense error d'autorització

Implementar una comprovació de propietat a l'endpoint: validar que el user_id de l'usuari autenticat coincideix amb el user_id associat a la factura sol·licitada abans de retornar les dades. Aplicar el mateix patró a tots els endpoints que reben IDs de recursos a la URL.

El camp "missatge" del formulari de suport no escapa correctament l'HTML enviat per l'usuari. Un atacant pot injectar codi JavaScript que s'executa quan un agent de suport obre el tiquet al panell d'administració.

Un atacant pot segrestar la sessió d'un agent de suport, robant cookies d'autenticació i obtenint accés al panell d'administració. En el pitjor escenari, això podria escalar a un control complet del sistema i de les dades de tots els clients.

1. Crear un tiquet de suport amb el missatge: '<script>alert(document.cookie)</script>'
2. L'agent de suport obre el tiquet al panell d'administració
3. El JavaScript s'executa en el context de l'agent, exposant les seves cookies de sessió

Escapar totes les sortides d'usuari a l'HTML del panell d'administració. Fer servir una llibreria de sanització com DOMPurify o aplicar codificació HTML estàndard en renderitzar text de l'usuari. Establir una Content-Security-Policy estricta com a defensa addicional.

Els tokens JWT generats per l'endpoint /api/auth/login no inclouen el claim "exp" (expiration). Els tokens són vàlids indefinidament un cop emesos, sense possibilitat d'invalidació individual.

Si un token es veu compromès (mitjançant phishing, malware al dispositiu de l'usuari, etc.), l'atacant manté accés al sistema permanentment. No hi ha manera d'invalidar el token sense rotar la clau de signatura del JWT, cosa que tancaria la sessió a tots els usuaris simultàniament.

1. Fer login a través de POST /api/auth/login
2. Capturar el token JWT de la resposta
3. Descodificar el token (jwt.io)
4. Confirmar que falta el camp "exp"
5. Fer servir el token 30 dies després: continua sent vàlid

Afegir un claim "exp" amb un temps de vida raonable (15-60 minuts per a tokens d'accés). Implementar un sistema de refresh tokens per a sessions de llarga durada. Establir una rotació periòdica de la clau de signatura del JWT.

El servidor web no retorna capçaleres de seguretat importants en les respostes HTTP: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options i Referrer-Policy. Aquestes capçaleres són la primera línia de defensa contra diversos tipus d'atacs de client.

Augmenta el risc d'atacs de clickjacking, XSS, downgrade a HTTP i filtració d'informació mitjançant el referrer. No són atacs directes però redueixen les defenses en profunditat i deixen l'usuari exposat a vectors d'atac que es podrien mitigar fàcilment.

1. Accedir a https://exemple.com amb curl
2. Inspeccionar les capçaleres de resposta: curl -I https://exemple.com
3. Verificar l'absència de les capçaleres esmentades

Configurar el servidor web (nginx/apache) o el proxy/CDN (Cloudflare, Vercel) per enviar les capçaleres de seguretat recomanades. Validar la configuració fent servir securityheaders.com.