Login, registrazione e recupero credenziali sono le porte di ingresso ai dati degli utenti. Un errore qui non è “solo” un bug: è una falla che apre a furti di identità, perdita di fiducia e problemi legali. L’obiettivo non è “far funzionare il login”, ma renderlo robusto, prevedibile e difeso su più livelli.
Scegli il modello di autenticazione giusto
- Siti server-rendered: la soluzione più lineare resta la sessione con cookie. È revocabile, semplice da gestire e si integra bene con protezioni anti-CSRF.
- Architetture API-first e più client (web, mobile): meglio token; se usi i JWT, gestisci bene durata, rotazione e revoca. In alternativa, token opachi con validazione lato server.
- “Accedi con Google/Apple” e Single Sign-On: OAuth2 + OpenID Connect per delegare identità in modo standard.
- Aree ad alto rischio (pagamenti, impostazioni account): aggiungi MFA e, quando possibile, passkey/WebAuthn.
Una regola semplice ma cruciale: i token vivono nei cookie HttpOnly (non nel localStorage) e i cookie devono essere sicuri (HTTPS, Secure, SameSite adeguato).
Sessioni fatte bene (e perché funzionano ancora)
Le sessioni restano una scelta eccellente per moltissime app:
Cookie protetti e scadenze chiare.
Rigenerazione dell’identificatore di sessione dopo il login per evitare fixation.
Logout che invalida davvero la sessione.
Anti-CSRF sulle azioni sensibili.
Timeout inattività + opzione “ricordami” gestita con criterio. Vantaggi: semplicità, revoca immediata, meno superfici d’attacco. Svantaggi: scalare su molti server richiede uno store condiviso, ma è gestibile.
Token e JWT: utili, ma con testa
I token brillano quando hai più client e microservizi. I JWT sono comodi perché contengono informazioni firmate, ma richiedono disciplina:
Durata breve per l’access token e refresh token separato.
Rotazione dei refresh token e possibilità di revoca immediata (allowlist/denylist).
Validazione seria: issuer, audience, scadenze.
Se non ti serve un “self-contained token”, i token opachi sono spesso più semplici e più sicuri da revocare.
OAuth2 + OpenID Connect: quando serve l’SSO
Integrare “Accedi con Google/Apple” riduce la gestione delle password e migliora la UX. Usa gli scope minimi, verifica i token lato server e conserva solo i dati strettamente necessari. Ricorda: l’SSO non elimina la sicurezza applicativa; sposta solo il problema dell’identità su un provider affidabile.
Password: policy onesta, storage corretto
Hash robusto (es. Argon2id o, in alternativa, bcrypt) con parametri aggiornati nel tempo.
Policy chiara e realistica: lunghezza minima sensata, controllo di password note come compromesse, limiti ai tentativi.
Verifica email e flusso di reset con link a scadenza breve e monouso.
Notifiche per cambi password, nuovi dispositivi e attività sospette.
MFA e passkey: la marcia in più
- MFA (TOTP, app di autenticazione o push) abbatte i rischi in caso di password rubata.
- Passkey/WebAuthn porta l’esperienza a un livello superiore: login con biometria del dispositivo e forte resistenza al phishing.
- Fornisci codici di recupero e un percorso di fallback per evitare lockout inutili.
Difese contro abusi e bot
- Rate limiting e backoff: più tentativi falliti, più attesa.
- Lockout temporaneo e sblocco assistito.
- Captcha “intelligente” solo dopo N errori, per non rovinare la UX.
- Monitoraggio degli IP anomali e segnalazioni all’utente in caso di accessi insoliti.
Recupero password senza spifferare nulla
Il flusso ideale non conferma mai se un’email esiste o meno. Invia il link solo se l’indirizzo è in archivio e mantieni il messaggio neutro (“Se esiste un account…”). Il token dev’essere unico, a scadenza breve e monouso. Alla fine del processo, notifica sempre l’esito.
Header, CORS e Content Security Policy
Pensa alle intestazioni di sicurezza come a una seconda armatura:
HSTS: forzare HTTPS.
CSP: limitare dove possono provenire script, stili, font e immagini.
CORS: aprire solo ciò che serve davvero.
Referrer-Policy e X-Frame-Options: meno superfici per clickjacking e leakage.
Sono dettagli “noiosi”, ma fanno una differenza enorme nel mondo reale.
Autorizzazione: ruoli, permessi e buon senso
Autenticare dice chi sei; autorizzare stabilisce cosa puoi fare.
Definisci ruoli e permessi con chiarezza (RBAC/ABAC).
Verifica sempre lato server.
Separa l’area admin dal resto, registra le azioni critiche e applica il principio del minimo privilegio.
Checklist operativa
- HTTPS ovunque, HSTS attivo.
- Cookie sicuri e niente token nel localStorage.
- Session ID rigenerato al login, anti-CSRF sulle form sensibili.
- Password con hash robusto, controlli su password compromesse.
- MFA attivabile, passkey quando possibile.
- Rate limiting, lockout, captcha solo quando serve.
- Reset password con token monouso a scadenza breve.
- Log e alert su accessi insoliti; audit per azioni importanti.
- CSP, CORS e header di sicurezza configurati.
- Ruoli/permessi chiari e controlli lato server.
Audit di sicurezza periodico
L’autenticazione non è “set and forget”. Pianifica audit trimestrali che verifichino: versioni dipendenze aggiornate, parametri hash password ancora adeguati, scadenze token e sessioni, log di accessi anomali, configurazione header di sicurezza, permessi ruoli e account di test disabilitati. Usa checklist OWASP ASVS o OWASP Top 10 come riferimento.
Automatizza dove possibile: Dependabot o Renovate per aggiornamenti, scan SAST in CI, test di penetrazione annuali su flussi auth critici. Documenta ogni modifica alla policy di sicurezza e comunica agli utenti cambiamenti rilevanti (es. obbligo MFA).
GDPR, privacy e dati di autenticazione
I dati di login (email, IP, timestamp accessi, device fingerprint) sono dati personali. Devi: informativa chiara su cosa raccogli e perché, base giuridica (contratto, legittimo interesse), minimizzazione (non conservare log oltre il necessario), diritto di accesso e cancellazione, notifica breach entro 72 ore se applicabile.
Evita di loggare password, token in chiaro o dati sensibili non necessari. Pseudonimizza dove possibile. Se usi provider OAuth, verifica i loro DPA e dove risiedono i dati. La sicurezza tecnica e la conformità privacy vanno di pari passo: un login sicuro ma opaco sul trattamento dati erode comunque la fiducia.
Testing: scenari da simulare prima del go-live
Prima di mettere in produzione un sistema di autenticazione, testa almeno questi scenari:
- Login con credenziali errate ripetute (rate limit attivo?)
- Reset password con email inesistente (messaggio neutro?)
- Session fixation: ID cambia dopo login?
- CSRF su form sensibili senza token
- Token JWT scaduto o manipolato
- Logout su un dispositivo invalida la sessione?
- MFA: codice errato, recovery code, dispositivo perso
- OAuth: scope eccessivi, revoca permessi lato provider
Strumenti utili: OWASP ZAP, Burp Suite Community, test manuali con account di staging. Meglio scoprire le falle tu che scoprirle qualcun altro.
Passkey nel 2025: stato dell’arte
Le passkey (WebAuthn/FIDO2) stanno diventando lo standard per login passwordless: resistenza al phishing, nessun segreto condiviso da rubare, UX con biometria del dispositivo. Apple, Google e Microsoft le supportano nativamente; i browser moderni le gestiscono senza plugin.
Per implementarle: usa librerie mature (SimpleWebAuthn, WebAuthn4J), offri fallback (password + MFA) per utenti legacy, spiega chiaramente il vantaggio in onboarding, testa su iOS, Android e desktop. Non è ancora obbligatorio ovunque, ma per nuovi progetti o aree sensibili è la direzione consigliata.
Conclusione
Scegli la soluzione più semplice che copre il tuo caso: sessioni per app classiche, token per API multi-client, OIDC per SSO. Aggiungi MFA/passkey, imposta bene cookie e header, cura i flussi “di contorno” (reset, lockout, notifiche). Non è solo sicurezza: è fiducia che costruisci con chi usa la tua applicazione.