En cada projecte nou, els equips de desenvolupament sovint es troben amb el mateix debat: emmagatzemem el token JWT a localStorage o en una cookie? Després d'anys de cicles repetitius, a Q2BSTUDIO hem consolidat un patró d'autenticació que apliquem de manera sistemàtica, ajustant només els detalls que cada aplicació requereix (com el suport per a clients mòbils o consumidors d'API de tercers amb tokens Bearer). Aquest patró no només elimina la incertesa tècnica, sinó que tanca la porta a vulnerabilitats comunes com XSS, CSRF o sessions segrestades per CORS mal configurat. En aquest article compartim l'estructura completa, les raons darrere de cada peça i com migrar des d'un sistema existent sense trencar res.
La decisió central: cookie httpOnly, mai emmagatzematge llegible per JS La clau del patró és emetre el token de sessió en una cookie amb les flags httpOnly, Secure i SameSite=Lax, a més de limitar el seu àmbit a un domini que funcioni a tots els subdominis. Aquesta cookie mai toca localStorage, sessionStorage ni cap variable accessible des de JavaScript. El motiu és directe: qualsevol dada que JavaScript pugui llegir pot ser extreta per un payload XSS. Una cookie httpOnly és invisible per a document.cookie i per a qualsevol script maliciós o inofensiu que s'executi a la pàgina. No és un luxe; és la diferència entre 'un bug XSS filtra la sessió' i 'un bug XSS no filtra res relacionat amb la sessió'. A Q2BSTUDIO, quan desenvolupem aplicacions a mida, aquest principi és innegociable, ja que la protecció de la sessió és la base de qualsevol sistema amb usuaris.
CSRF doble enviament, només on cal L'autenticació basada en cookies reintrodueix el risc de CSRF que un token Bearer en una capçalera no té (el navegador adjunta cookies automàticament, però no capçaleres personalitzades). Per mitigar-lo, fem servir una segona cookie llegible per JavaScript que conté un valor CSRF, i el frontend el reenvia com a capçalera de sol·licitud a cada mutació. El servidor comprova que ambdós coincideixin. Aquesta protecció només és necessària per a operacions d'escriptura — les lectures no requereixen validació CSRF — i no aplica en absolut a clients que utilitzen exclusivament tokens Bearer, ja que mai van ser vulnerables a aquest atac. En els nostres projectes de ciberseguretat, implementar aquesta doble verificació és una de les primeres mesures que recomanem per evitar que un atacant pugui executar accions en nom d'un usuari autenticat.
CORS: llista blanca, mai comodí, especialment amb credencials La combinació de Access-Control-Allow-Origin: * amb credentials: true és perillosa: permet que qualsevol lloc segresti les sessions dels teus usuaris. La solució és una llista blanca explícita d'orígens, amb credentials: true i mai un comodí ni un reflex dinàmic de la capçalera Origin. A Q2BSTUDIO, en desplegar infraestructura a cloud AWS/Azure, configurem els serveis perquè el middleware CORS rebutgi qualsevol origen no autoritzat. Això evita que un atac de 'session riding' aprofiti una configuració permissiva.
TOTP 2FA per a qualsevol rol privilegiat Qualsevol usuari amb permisos elevats (administradors, gestors, etc.) ha de passar per un flux d'autenticació de dos factors basat en TOTP (Time-based One-Time Password). El setup, enable i disable segueixen un procés estàndard, i un cop activat, el 2FA és obligatori a cada inici de sessió. Implementar-lo és barat comparat amb el valor que aporta: una capa extra que protegeix comptes amb accés a dades sensibles, operacions financeres o configuracions crítiques. En entorns on integrem BI / Power BI, per exemple, els dashboards de negoci solen estar exposats a perfils que requereixen aquesta protecció addicional.
Migrar des d'un sistema amb tokens Bearer sense trencar el funcionament actual La part pràctica que fa que aquest patró sigui adoptable en un projecte en viu és la migració en mode dual. Els guardes d'autenticació accepten tant la cookie httpOnly com la capçalera Authorization; les comprovacions CSRF només s'apliquen a la ruta de la cookie. L'endpoint de login continua retornant el token al cos de la resposta (per a clients que usen Bearer) mentre també estableix la cookie. Cap integració existent es trenca, i el frontend pot migrar progressivament. Així ho hem fet en múltiples projectes de Q2BSTUDIO, des de plataformes d'IA fins a sistemes que incorporen agents IA per a automatització de processos.
Llista de verificació abans de donar per acabat el patró A cada projecte verifiquem els punts següents: (1) El login estableix realment una cookie httpOnly (comprovant les capçaleres de resposta, no només que 'sembla que funciona'). (2) Les sol·licituds basades en cookie funcionen sense necessitat d'adjuntar manualment el token. (3) Una mutació sense la capçalera CSRF és rebutjada amb 403, no acceptada silenciosament. (4) Una sol·licitud des d'un origen no permès no rep la capçalera Access-Control-Allow-Origin. (5) El logout elimina ambdues cookies, no només la sessió del costat servidor. Saltar qualsevol d'aquestes comprovacions converteix 'implementem protecció CSRF' en 'implementem una capçalera CSRF que ningú valida'.
Què li diria al meu jo del passat Decideix el patró d'autenticació una vegada, fes-lo bé i reutilitza'l. No reobris el debat localStorage vs cookie a cada projecte nou. La combinació de CORS amb comodí i credencials és la forma més fàcil de construir accidentalment una vulnerabilitat de segrest de sessió. Fes que sigui impossible d'enviar a producció, no només que estigui documentat com a incorrecte. Un pla de migració que mantingui funcionant els clients antics és el que realment permet adoptar un patró endurit en una aplicació en viu — les propostes de 'reescriu-ho tot' moren a les reunions de planificació. A Q2BSTUDIO, apliquem aquesta filosofia a cada desenvolupament, garantint que la seguretat no sigui un afegit tardà sinó un pilar des del primer dia.
