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.

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.