Il banner chiede un consenso. Non mette HttpOnly sulla sessione. Secure, HttpOnly e SameSite si spediscono nell’header di risposta. SameSite=None richiede Secure.
Il banner dei cookie chiede un consenso. Non imposta i flag sul cookie di sessione. Secure, HttpOnly e SameSite si scrivono nell’header di risposta che imposta il cookie, lato server. Un plugin di CMP che inserisce uno script in pagina può coprire il marketing. Sulla sessione, se l’applicazione spedisce il cookie di runtime senza flag, lo script del banner non ci arriva.
In breve: Secure manda il cookie solo su HTTPS. HttpOnly lo toglie agli script in pagina. SameSite=Lax o Strict limita l’invio cross-site; None richiede Secure. I prefissi Host e Secure sul nome vincolano il cookie. OWASP li tratta come attributi di sessione, non come testo del banner. Verifica del 17 settembre 2026 su MDN e sulle cheat sheet OWASP.
Cosa trovi in questo articolo
Cosa fa un cookie, e cosa non è il banner
MDN, nella guida Using HTTP cookies, tratta il cookie come coppia nome-valore che il server spedisce in un header di risposta e il browser rimanda. Per più cookie, più header. Quell’header è filtrato dal browser verso il JavaScript in pagina: lo script non lo legge. Il cookie di sessione nasce lì, non nel testo del popup «Accetta tutti».
Il banner, sotto GDPR, è un consenso su cookie non necessari. Marketing, profilazione, terze parti. La sessione di login, il carrello, il token anti-forgery in cookie, restano mestiere dell’applicazione. Un CMP che gira in pagina non può aggiungere HttpOnly a un cookie che il server ha già messo senza. Può, al più, scrivere altri cookie da script: quelli, per costruzione, non sono HttpOnly.
Questo pezzo sta nel cluster Sicurezza, accanto a HSTS, CSP e al certificato TLS. HSTS tiene il browser su HTTPS. La CSP limita gli script. I flag del cookie dicono al browser quando rimandare quel nome, e a chi in pagina è vietato leggerlo. Tre strati. Il plugin «cookie banner premium» non è il terzo.
Tre flag: Secure, HttpOnly, SameSite
OWASP, nella Session Management Cheat Sheet, elenca gli attributi del cookie di sessione. MDN ne fissa la sintassi nella guida sui cookie HTTP. Tre mestieri, e tre limiti:
| Attributo | Cosa fa, se c’è | Cosa non fa da solo |
|---|---|---|
Secure | Il browser lo spedisce solo su HTTPS | Non emette il certificato. Quello sta in TLS. Senza HSTS, la prima richiesta in chiaro resta un altro problema |
HttpOnly | Toglie il cookie all’API JavaScript dei cookie e agli script in pagina | Non chiude un XSS. Un XSS può ancora fare richieste col cookie in automatico. Serve la CSP e output sanificato |
SameSite=Strict | Il cookie non parte su nessuna richiesta cross-site | Rompe i ritorni da un pagamento o da un IdP su un altro dominio, se la sessione sta su quel cookie |
SameSite=Lax | Parte sui GET top-level cross-site, non sui POST cross-site classici | Non è una difesa CSRF completa: OWASP lo mette tra le difese in profondità |
SameSite=None con Secure | Parte anche in contesto third-party | MDN: None richiede Secure. Senza, il browser scarta il cookie |
Esempio minimo di sessione, da tenere sul server, non in un snippet del tema: nome del cookie, percorso radice, flag Secure, flag HttpOnly, SameSite Lax. Si spedisce come header di risposta, non si incolla nel HTML del tema.
I browser moderni trattano come Lax un cookie senza SameSite. Non è una scusa per omettere l’attributo: il default è un comportamento del browser, non un contratto della tua applicazione. Max-Age e Expires decidono quanto vive; un attributo Domain troppo largo (l’intero eTLD+1) allarga la superficie ai sottodomini. OWASP consiglia Path e Domain stretti.
Prefissi sul nome: Host e Secure
MDN documenta i cookie name prefixes. Non sono un plugin. Sono un vincolo sul nome, applicato dal browser:
| Prefisso | Il browser lo accetta solo se |
|---|---|
| prefisso Secure sul nome | C’è Secure, e la risposta è su HTTPS |
| prefisso Host sul nome | C’è Secure, percorso radice, e non c’è l’attributo Domain |
Il prefisso Host è il nome di sessione più stretto che il browser sa imporre: vale solo per quell’host, solo su HTTPS, solo sulla radice. Un sottodominio compromesso non se lo fa spedire allargando Domain. Se il CMS ha bisogno del cookie su www e su un host applicativo, il prefisso Host non è la scelta giusta: si fa un inventario, non si spegne il prefisso «perché il plugin login non parte».
SameSite non sostituisce il token anti-forgery
La CSRF Prevention Cheat Sheet mette SameSite tra le difese in profondità. Poi elenca i limiti: non copre i sottodomini dello stesso sito come se fossero origini distinte nel senso che conta per te; Lax lascia passare i GET top-level; i cookie None per i widget third-party restano esposti. OWASP continua a chiedere un token (synchronizer o double-submit firmato) sulle operazioni che cambiano stato.
Un plugin «anti-CSRF» che gira in pagina, come il plugin «anti-XSS» del pezzo sulla CSP, è un altro script. Il token va legato alla sessione lato server. SameSite riduce la finestra. Non la chiude.
Errori da evitare
Credere che il banner del consenso abbia «messo i cookie in sicurezza».
Sessione senza
HttpOnly: uno script in pagina può leggere il valore del cookie.Sessione senza
Securesu un sito che «ha già HTTPS»: il cookie parte anche sul primo hop in chiaro, se ci arrivi.SameSite=NonesenzaSecure: il browser lo scarta.SameSite=Strictsulla sessione di un checkout che torna da un PSP su un altro dominio, e poi sorprendersi dei logout.Allargare Domain all’intero albero di host «per fare funzionare il sottodominio», e regalare il cookie a ogni nome di quell’albero.
Confondere il cookie di sessione con i cookie del CMP: due header, due vite, due rischi.
In sintesi
Il cookie di sessione è un header di risposta. Si spedisce con Secure, HttpOnly e un SameSite scelto. I prefissi Host e Secure sul nome stringono il vincolo. Il banner del consenso è un altro mestiere. SameSite non sostituisce il token anti-forgery. HSTS, CSP e TLS restano tre strati a parte: il plugin che promette tutti e quattro è un quarto script.
Fonti
MDN, Using HTTP cookies (consultata il 17 settembre 2026): sintassi,
Secure,HttpOnly,SameSite, prefissi,NonerichiedeSecure.OWASP, Session Management Cheat Sheet: attributi del cookie di sessione, Domain/Path, prefissi.
OWASP, CSRF Prevention Cheat Sheet: SameSite come difesa in profondità, limiti, token.
Immagine di copertina: rack di server. Foto di Derrick Coetzee, Wikimedia Commons, licenza CC0 (pubblico dominio). I flag del cookie si impostano sulla risposta HTTPS, non da uno script in pagina.
Questo contenuto è stato realizzato con il supporto di sistemi di intelligenza artificiale e successivamente verificato secondo le linee editoriali della redazione.
