Cosa sono i flag di sicurezza dei cookie?

Ogni volta che il tuo sito WordPress imposta un cookie — che sia per sessioni di login, carrelli, analisi o preferenze di consenso — quel cookie può portare con sé un insieme di flag di sicurezza. Questi flag indicano al browser come gestire il cookie: quando inviarlo, chi può leggerlo e su quali connessioni può viaggiare. Impostarli in modo errato non causa problemi visibili, ma apre la porta ad attacchi che la maggior parte dei proprietari di siti nota solo quando è troppo tardi.

Il flag Secure

Un cookie con il flag Secure viene inviato solo su connessioni HTTPS. Il browser rifiuta semplicemente di includerlo nelle richieste HTTP non crittografate.

Set-Cookie: session_id=abc123; Secure

Perché è importante? Immagina un visitatore che accede al tuo sito sul Wi-Fi di un bar. Se per caso carica una pagina tramite HTTP semplice — ad esempio attraverso un vecchio segnalibro o una configurazione di reindirizzamento errata — i cookie normalmente viaggerebbero in chiaro sulla rete. Chiunque ascolti quel traffico Wi-Fi può catturare il cookie di sessione e impersonare l'utente. Con il flag Secure, il browser trattiene completamente il cookie in questo scenario.

Poiché il tuo sito WordPress dovrebbe comunque funzionare su HTTPS (e deve farlo — non ci sono più scuse nel 2025), impostare questo flag non costa nulla e previene una vera classe di attacchi.

Il flag HttpOnly

Il flag HttpOnly impedisce a JavaScript di accedere al cookie tramite document.cookie. Il cookie viene comunque inviato normalmente con le richieste HTTP, ma nessuno script lato client può leggerlo o manipolarlo.

Set-Cookie: session_id=abc123; HttpOnly

Questo flag esiste specificamente per limitare i danni degli attacchi Cross-Site Scripting (XSS). Se un aggressore riesce a iniettare JavaScript nella tua pagina — tramite un plugin vulnerabile, un campo commento o un vettore XSS memorizzato — una delle prime cose che lo script tenta è document.cookie per rubare i token di sessione. Con HttpOnly impostato, quella chiamata non restituisce nulla per i cookie protetti.

Non impedisce l'XSS in sé. Non risolve la vulnerabilità sottostante. Ma toglie il premio più prezioso — i cookie di sessione — dal tavolo, il che spesso fa la differenza tra un fastidio e un completo takeover dell'account.

Il flag SameSite

L'attributo SameSite controlla il comportamento dei cookie cross-site. Determina se il browser invia un cookie quando una richiesta proviene da un dominio diverso da quello che ha impostato il cookie.

Esistono tre valori possibili:

• SameSite=Strict — Il cookie non viene mai inviato con richieste cross-site. Punto. Se qualcuno clicca su un link al tuo sito da una pagina esterna, il cookie di sessione non viene inviato con quella richiesta iniziale. Questa è l'impostazione più restrittiva e può causare problemi di usabilità (gli utenti sembrano disconnessi quando arrivano da link esterni).
• SameSite=Lax — Il cookie viene inviato con le navigazioni di primo livello (clic su un link), ma non con richieste embedded come immagini, iframe o invii di moduli da altri siti. Questa è l'impostazione predefinita dei browser dal Chrome 80 (2020) e offre un buon equilibrio tra sicurezza e usabilità.
• SameSite=None — Il cookie viene inviato con tutte le richieste, indipendentemente dall'origine. È necessario per casi d'uso legittimi di cookie di terze parti (moduli di pagamento incorporati, SSO, annunci), ma deve sempre essere combinato con il flag Secure — i browser rifiutano SameSite=None senza Secure.

Set-Cookie: session_id=abc123; SameSite=Lax

La principale minaccia che SameSite affronta è il Cross-Site Request Forgery (CSRF) — attacchi in cui un sito malevolo inganna il tuo browser facendogli inviare richieste autenticate al tuo sito WordPress a tua insaputa.

Mettere tutto insieme

Per i cookie di autenticazione e di sessione, la configurazione consigliata è:

Set-Cookie: session_id=abc123; Secure; HttpOnly; SameSite=Lax; Path=/

Ogni flag copre un vettore di attacco diverso:

• Secure — previene l'intercettazione a livello di rete
• HttpOnly — previene il furto a livello di script (XSS)
• SameSite — previene l'abuso cross-origin (CSRF)

La mancanza di uno qualsiasi di essi lascia una breccia. Funzionano come una squadra.

E i cookie di terze parti?

I cookie impostati da servizi esterni caricati sul tuo sito (analisi, widget di chat, pixel pubblicitari) non sono sotto il tuo controllo diretto. I loro flag di sicurezza sono determinati dal servizio che imposta il cookie. Ma dovresti esserne consapevole — un cookie di terze parti senza Secure o con SameSite=None crea esposizione sul tuo dominio, anche se non hai impostato tu stesso il cookie.

Questo è particolarmente rilevante per la conformità GDPR: sapere quali cookie vengono impostati sul tuo sito e come sono configurati è parte della tua responsabilità di amministratore del sito.

Come aiuta InspectWP

InspectWP esamina ogni cookie impostato durante il caricamento di una pagina sul tuo sito WordPress e segnala quelli senza gli attributi Secure, HttpOnly o SameSite. Il report mostra ogni cookie con i suoi flag attuali, così puoi vedere rapidamente quali necessitano di attenzione — siano essi originati dal core di WordPress, dai plugin o da script di terze parti.