Sessioni ecommerce sicure: cookie, SameSite, rotazione e logout

La sessione è una credenziale, non un dettaglio del login

Dopo un'autenticazione riuscita, il browser presenta a ogni richiesta un segreto che collega il cliente al suo stato autenticato. Chi ottiene quel segreto può spesso agire con gli stessi privilegi fino alla scadenza o alla revoca. Per questo passkey, MFA e password robuste non bastano se la sessione resta troppo lunga, riutilizzabile dopo il logout o esposta a script e sottodomini non necessari. In un ecommerce il problema attraversa account, carrello, indirizzi, ordini, metodi di pagamento salvati e back office: il ciclo di vita deve essere progettato come quello di una credenziale.

Il modello più controllabile usa nel cookie soltanto un identificatore opaco e casuale. Profilo, ruoli, scadenze e decisioni di autorizzazione restano sul server. Non inserite email, prezzi, permessi o logica commerciale nel valore della sessione. Generate l'identificatore con un generatore crittograficamente sicuro: NIST richiede almeno 64 bit di entropia per il segreto di sessione, mentre OWASP raccomanda almeno 128 bit quando si costruisce un formato personalizzato. Non accettate mai identificatori che il sistema non ha emesso.

Delimitare il cookie al perimetro minimo

Attributi che riducono l'esposizione

Secure limita l'invio del cookie alle connessioni HTTPS; HttpOnly impedisce alle API JavaScript di leggerlo. Questi attributi riducono due superfici diverse e vanno usati insieme, senza considerarli una cura universale per XSS o traffico intercettato. Se la sessione appartiene a un singolo host, il prefisso __Host-, Path=/ e l'assenza di Domain impediscono di allargarne inutilmente l'ambito ai sottodomini.

Una base ragionevole può assomigliare a Set-Cookie: __Host-session=<opaque>; Path=/; Secure; HttpOnly; SameSite=Lax. Non è una configurazione da copiare senza analisi: persistenza, durata e SameSite dipendono dai flussi reali. Evitate di impostare un Domain ampio per comodità e separate le sessioni amministrative da quelle dello storefront. Un'applicazione compromessa su un sottodominio non dovrebbe poter influenzare il cookie del checkout.

Scegliere SameSite in base al percorso

SameSite=Lax è spesso un punto di partenza equilibrato perché limita molti invii cross-site conservando alcune navigazioni di primo livello. Strict offre un perimetro più rigido ma può interrompere rientri legittimi. None serve soltanto quando il cookie deve davvero attraversare contesti cross-site e richiede anche Secure. Mappate login federato, redirect del pagamento, assistenza incorporata e domini del checkout prima di irrigidire il valore. Il comportamento va verificato su browser e percorsi effettivamente supportati.

Ruotare l'identificatore nei cambi di fiducia

La session fixation nasce quando un identificatore conosciuto prima del login resta valido dopo l'autenticazione. La difesa principale è rigenerare l'ID nel passaggio da visitatore anonimo a cliente autenticato e invalidare quello precedente. La stessa regola vale dopo reset della password, modifica dei privilegi, attivazione di un ruolo amministrativo o altra elevazione di fiducia. Aggiungere un nuovo cookie senza distruggere il vecchio lascia aperto il percorso che si voleva chiudere.

La rotazione richiede una transizione atomica: il repository crea il nuovo record, trasferisce solo lo stato necessario e rende il vecchio ID inutilizzabile. Gestite con attenzione due richieste parallele durante il cambio, evitando finestre indefinite in cui entrambi gli identificatori funzionano. Per i carrelli anonimi, collegate i dati all'account con una regola esplicita e controlli di proprietà; non trasformate automaticamente ogni stato fornito dal browser in stato autenticato.

Applicare timeout e validità sul server

Idle timeout e durata assoluta

Il timestamp del cookie nel browser non è la fonte autorevole della validità. Il server deve applicare un idle timeout, che chiude le sessioni inattive, e una durata assoluta, che impone un nuovo accesso anche quando l'utente continua a usare il sito. I valori non sono universali: storefront, area ordini e back office hanno rischio e tolleranza differenti. Una sessione più lunga può ridurre attrito, ma amplia la finestra in cui un segreto sottratto rimane utile.

Registrate ultimo utilizzo, creazione e scadenza nel repository della sessione e controllateli a ogni richiesta protetta. Evitate di aggiornare il record a ogni risorsa statica; rinnovate secondo una cadenza controllata e proteggete lo storage da scritture eccessive. Un deploy o un failover non deve riattivare record scaduti. Definite inoltre come revocare tutte le sessioni di un account quando viene rilevato un rischio.

Richiedere nuova autenticazione per azioni sensibili

Una sessione valida non prova che l'utente sia ancora davanti al dispositivo. Cambio di password o email, gestione dei pagamenti e aumento dei privilegi meritano una verifica recente. La reautenticazione può creare un livello di fiducia temporaneo, separato dalla sessione di navigazione. Conservate sul server quando è avvenuta e per quali azioni vale; non deducetela da un parametro del client.

Fare del logout una revoca reale

Il logout deve invalidare il record server-side e poi far scadere il cookie nel browser con gli stessi attributi di scope usati in emissione. Cancellare soltanto il cookie lascia valido un valore copiato; invalidare soltanto il server senza pulire il client genera invece richieste confuse. Su pagine sensibili, Cache-Control: no-store riduce il rischio che risposte autenticate restino in cache. Clear-Site-Data può aiutare a pulire dati del sito, ma non sostituisce la revoca.

Nei flussi federati distinguete la sessione ecommerce da quella dell'identity provider. Terminare una non implica sempre terminare l'altra: documentate il comportamento e non promettete un logout globale se l'integrazione non lo garantisce. Offrite, quando appropriato, la vista delle sessioni attive e la possibilità di revocarle da un dispositivo fidato. Ogni evento di logout deve produrre un esito osservabile, non soltanto un redirect.

Usare SameSite come difesa in profondità contro CSRF

SameSite riduce alcuni invii automatici del cookie da siti esterni, ma non esaurisce la difesa CSRF. Le operazioni che modificano indirizzi, carrello, account o ordini devono usare la protezione prevista dal framework o un token CSRF correttamente legato alla sessione. Non cambiate stato con richieste GET e verificate origine o contesto quando l'architettura lo consente. I flussi cross-site necessari vanno isolati e validati, non esclusi in blocco dai controlli.

Trattate callback di pagamento e login come protocolli con stato proprio: verificate nonce, correlazione e destinazione, quindi create o aggiornate la sessione soltanto dopo la validazione. Un allentamento globale a SameSite=None per correggere un singolo redirect espone ogni richiesta; preferite cookie o endpoint separati quando il disegno lo permette. Testate anche browser con politiche più restrittive e casi di ritorno dopo inattività.

Osservare il ciclo di vita senza registrare segreti

La telemetria dovrebbe coprire emissione, rotazione, rinnovo, scadenza, revoca, logout, ID sconosciuti e fallimenti di reautenticazione. Non salvate l'identificatore grezzo nei log. Se serve correlare eventi, usate un derivato non reversibile con chiave protetta e una retention limitata. Separate il correlatore tecnico dall'identità commerciale e applicate accessi minimi ai dati operativi.

Misurate tasso di ID sconosciuti, rinnovi falliti, logout non completati, sessioni revocate ancora accettate e callback respinte dopo modifiche a SameSite. Un valore anomalo deve portare a un'azione: revoca, rollback della configurazione, indagine o correzione del client. Aggiungete test automatici che tentino di riusare il vecchio ID dopo login, cambio privilegi e logout, oltre a prove di timeout con un orologio controllato.

Rilasciare una policy verificabile

Inventariate prima tutti i cookie di autenticazione e i flussi cross-site. Introducete scope minimo e attributi in un ambiente osservabile, poi abilitate rotazione, timeout e revoca con test di concorrenza. Preparate una procedura per invalidare sessioni in massa senza fermare il checkout e una strategia di rollback che non riaccetti ID già revocati. La checklist di rilascio deve includere browser supportati, redirect esterni, cache, failover dello storage e separazione del back office.

Una sessione sicura è un sistema coordinato, non una singola direttiva Set-Cookie. Cookie, repository, autorizzazione, callback, log e supporto devono condividere la stessa definizione di validità. I servizi ecommerce e sistemi di AE Digital Agency possono trasformare questa policy in controlli testabili, metriche operative e un rollout compatibile con il percorso di acquisto.