Un cookie di sessione è la chiave della tua sessione autenticata – e proteggerlo con i flag giusti è appsec di base che tanti sbagliano ancora. I tre che contano:
- HttpOnly – il cookie non è accessibile da JavaScript: neutralizza il furto del cookie via XSS (uno script iniettato non può leggerlo per esfiltrarlo). Fondamentale per i cookie di sessione
- Secure – il cookie viene inviato solo su HTTPS: impedisce che viaggi in chiaro e venga intercettato (su una rete ostile)
- SameSite – controlla se il cookie viene inviato nelle richieste cross-site:
StrictoLax(il default moderno) proteggono dal CSRF (un altro sito non può far partire richieste autenticate a tuo nome).None(che richiedeSecure) solo quando il cross-site serve davvero
Gli attributi complementari: un nome senza informazioni, uno scope stretto (Path, Domain minimi), una scadenza ragionevole (i cookie di sessione lunghi sono comodi e rischiosi), e la rotazione del token di sessione al login (contro il session fixation).
Sono poche righe di configurazione con un impatto enorme – e la loro assenza è un classico rilievo dei security assessment. Insieme a security header, CSP e HTTPS, sono l'igiene di base di qualsiasi applicazione web che gestisca sessioni – i framework moderni li impostano bene di default, ma verificarlo (con gli strumenti dev del browser) è due minuti ben spesi.