Risolvere i flag di sicurezza dei cookie in WordPress

Se InspectWP segnala cookie senza i flag Secure, HttpOnly o SameSite, il tuo sito potrebbe essere vulnerabile a session hijacking, furto di cookie basato su XSS o attacchi di cross-site request forgery (CSRF). Questi tre flag sono i più importanti attributi di sicurezza dei cookie e insieme proteggono i dati di sessione dei tuoi utenti. Fortunatamente, risolverli in WordPress è semplice una volta che capisci cosa fa ciascun flag e dove applicarlo.

Comprendere i flag di sicurezza dei cookie e il loro scopo

Prima di applicare le correzioni, aiuta capire da cosa protegge ciascun flag:

• Flag Secure: Garantisce che il cookie venga inviato solo su connessioni HTTPS. Senza questo flag, un cookie può essere trasmesso su HTTP non crittografato, permettendo a un aggressore sulla stessa rete (ad es. Wi-Fi pubblico) di intercettarlo con un semplice packet sniffer. Una volta in possesso del cookie di sessione, possono impersonare l'utente. Questo attacco è noto come session hijacking o sidejacking.
• Flag HttpOnly: Impedisce a JavaScript di accedere al cookie tramite document.cookie. Questa è una protezione cruciale contro gli attacchi cross-site scripting (XSS). Se un aggressore riesce a iniettare JavaScript malevolo nella tua pagina (tramite un plugin vulnerabile, un campo commento o un input utente), il flag HttpOnly impedisce a quello script di leggere i cookie di sessione e inviarli a un server esterno.
• Flag SameSite: Controlla se il cookie viene inviato con richieste cross-site. Questo protegge dagli attacchi CSRF, in cui un sito malevolo inganna il browser di un utente facendogli inviare richieste autenticate al tuo sito. L'attributo SameSite ha tre valori possibili:
  • Strict: Il cookie non viene mai inviato con richieste cross-site. Questo fornisce la protezione più forte, ma può rompere i flussi di login quando gli utenti cliccano su link da fonti esterne come email o altri siti web.
  • Lax: Il cookie viene inviato con la navigazione di primo livello (cliccando su un link), ma non con richieste embedded (immagini, iframe, AJAX). Questa è l'impostazione predefinita consigliata per la maggior parte dei siti WordPress.
  • None: Il cookie viene inviato con tutte le richieste, comprese quelle cross-site. Deve essere combinato con il flag Secure ed è necessario solo per i cookie che devono funzionare in contesti cross-site, come integrazioni di provider di pagamento o widget embedded.

Rafforzare i cookie di autenticazione di WordPress

WordPress imposta diversi cookie per gli utenti loggati, inclusi wordpress_logged_in_* e wordpress_sec_*. Questi sono i cookie più sensibili dal punto di vista della sicurezza sul tuo sito, perché controllano l'accesso admin. Per rafforzarli, aggiungi le seguenti costanti al tuo file wp-config.php, prima della riga che dice "That's all, stop editing!":

// Forza l'invio dei cookie solo su HTTPS
define('FORCE_SSL_ADMIN', true);

// Imposta dominio e percorso dei cookie
define('COOKIE_DOMAIN', 'example.com');
define('COOKIEPATH', '/');

// Rafforza i cookie di sessione PHP
@ini_set('session.cookie_secure', '1');
@ini_set('session.cookie_httponly', '1');
@ini_set('session.cookie_samesite', 'Lax');

La costante FORCE_SSL_ADMIN è particolarmente importante. Forza WordPress a usare HTTPS per il pannello admin e le pagine di login, garantendo che i cookie di autenticazione vengano impostati solo su connessioni crittografate. Senza di essa, un utente che effettua il login tramite HTTP trasmetterebbe le sue credenziali e i cookie in chiaro.

Nota che @ini_set influisce solo sui cookie di sessione PHP, non sui cookie specifici di WordPress. WordPress usa le proprie funzioni di impostazione dei cookie che non dipendono dalle sessioni PHP. Per proteggere specificamente i cookie WordPress, hai bisogno degli approcci a livello di server descritti di seguito.

Impostare i flag dei cookie tramite la configurazione PHP

Per PHP 7.3 e successivi, puoi impostare attributi cookie predefiniti che si applicano a tutti i cookie creati dalla funzione setcookie() di PHP. Aggiungili al tuo file php.ini se hai accesso:

session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = Lax

Se non hai accesso a php.ini (comune sull'hosting condiviso), puoi invece impostare questi valori nel tuo file .htaccess:

# Imposta i valori predefiniti di cookie sicuri per le sessioni PHP
php_value session.cookie_secure 1
php_value session.cookie_httponly 1
php_value session.cookie_samesite "Lax"

Tieni presente che queste impostazioni si applicano solo ai cookie creati tramite la gestione nativa delle sessioni di PHP. Il core di WordPress e la maggior parte dei plugin usano direttamente setcookie() o wp_set_auth_cookie(), che non ereditano automaticamente queste impostazioni ini. Per una copertura completa, l'approccio a livello di server tramite gli header è più affidabile.

Risolvere tutti i cookie tramite Apache .htaccess

Il modo più affidabile per aggiungere flag di sicurezza a ogni cookie su un server Apache è modificare l'header Set-Cookie a livello di server. Questo intercetta tutti i cookie, inclusi quelli impostati dal core di WordPress, dai plugin e da script di terze parti:

# Aggiungi flag di sicurezza a tutti i cookie
<IfModule mod_headers.c>
    Header always edit Set-Cookie ^(.*)$ "$1; Secure; HttpOnly; SameSite=Lax"
</IfModule>

Posizionalo nel file .htaccess principale del tuo sito. La direttiva Header always edit usa un'espressione regolare per abbinare tutti gli header Set-Cookie e aggiunge i flag di sicurezza a ciascuno.

C'è un avvertimento importante con questo approccio. Se un cookie ha già uno di questi flag (ad es. un plugin imposta autonomamente Secure), puoi finire con flag duplicati come Secure; Secure. La maggior parte dei browser gestisce ordinatamente i duplicati, ma un approccio più pulito usa una negative lookahead per evitare di aggiungere flag già presenti:

<IfModule mod_headers.c>
    # Aggiungi il flag Secure se non già presente
    Header always edit Set-Cookie "^((?!.*Secure).*)$" "$1; Secure"

    # Aggiungi il flag HttpOnly se non già presente
    Header always edit Set-Cookie "^((?!.*HttpOnly).*)$" "$1; HttpOnly"

    # Aggiungi SameSite=Lax se nessun attributo SameSite è presente
    Header always edit Set-Cookie "^((?!.*SameSite).*)$" "$1; SameSite=Lax"
</IfModule>

Questa versione controlla ogni cookie separatamente e aggiunge il flag solo se non è già lì. È più verboso ma evita potenziali problemi con attributi duplicati.

Risolvere tutti i cookie tramite la configurazione Nginx

Per i server Nginx, l'approccio dipende dalla tua versione di Nginx:

Nginx 1.19.3 e successivi supporta nativamente la direttiva proxy_cookie_flags:

# Nel tuo blocco server o location
proxy_cookie_flags ~ secure httponly samesite=lax;

La ~ abbina tutti i cookie. Puoi anche puntare a cookie specifici per nome:

# Applica solo ai cookie di sessione WordPress
proxy_cookie_flags wordpress_logged_in_* secure httponly samesite=lax;
proxy_cookie_flags wordpress_sec_* secure httponly samesite=lax;

Versioni Nginx precedenti (precedenti alla 1.19.3) possono usare la direttiva proxy_cookie_path come workaround:

# Workaround per versioni Nginx precedenti
proxy_cookie_path / "/; Secure; HttpOnly; SameSite=Lax";

Se usi Nginx come reverse proxy davanti ad Apache o PHP-FPM, potresti dover aggiungere header anche tramite il modulo more_set_headers o la direttiva add_header. Tuttavia, add_header non modifica gli header Set-Cookie, quindi proxy_cookie_flags è l'approccio corretto.

Risolvere i cookie su siti proxied tramite Cloudflare o CDN

Se il tuo sito WordPress è dietro Cloudflare o un altro proxy CDN, c'è uno strato aggiuntivo nella gestione dei cookie. Cloudflare imposta i suoi cookie (come __cf_bm per la gestione dei bot), e questi cookie sono gestiti da Cloudflare, non dalla configurazione del tuo server. Non puoi aggiungere flag di sicurezza ai cookie di Cloudflare tramite .htaccess o configurazione Nginx.

I cookie di Cloudflare già includono i flag Secure e HttpOnly per impostazione predefinita. Se InspectWP segnala un cookie Cloudflare come mancante di un flag, probabilmente si tratta di un problema di visualizzazione o di un cookie da una funzione Cloudflare che omette deliberatamente determinati flag (ad es. cookie analitici che richiedono accesso JavaScript e quindi mancano di HttpOnly).

Per i cookie impostati dal tuo server di origine, le soluzioni .htaccess o Nginx descritte sopra funzionano correttamente anche quando Cloudflare è davanti. Cloudflare inoltra gli header Set-Cookie dal tuo server al client senza modifiche.

Affrontare i cookie dei plugin che mancano di flag di sicurezza

Molti plugin WordPress impostano i propri cookie, e non tutti includono flag di sicurezza corretti. I colpevoli comuni includono:

• Plugin di consenso ai cookie: Plugin come CookieYes, Complianz o GDPR Cookie Consent impostano cookie per ricordare la scelta di consenso dell'utente. Controlla nelle impostazioni di ciascun plugin un'opzione "Cookie sicuri" o "Sicurezza dei cookie". Alcuni plugin hanno aggiunto queste opzioni nelle versioni recenti.
• Plugin di analisi e tracciamento: Google Analytics, Matomo e plugin simili possono impostare cookie di tracciamento senza flag di sicurezza. L'approccio a livello di server (Apache/Nginx) è la migliore soluzione per questi, poiché i plugin raramente offrono configurazione dei flag dei cookie.
• Plugin di caching: WP Rocket, LiteSpeed Cache e altri impostano cookie identificativi della cache che possono mancare di flag. Anche qui, l'approccio a livello di server gestisce questo automaticamente.
• WooCommerce: WooCommerce imposta diversi cookie per i dati del carrello e la gestione delle sessioni. Le versioni recenti di WooCommerce (5.0+) impostano il flag Secure quando il sito usa HTTPS, ma le versioni precedenti potrebbero non farlo. Aggiorna WooCommerce all'ultima versione e applica la correzione header a livello di server come rete di sicurezza.
• Plugin di login e abbonamento: Plugin come MemberPress, Restrict Content Pro o WP-Members possono impostare i propri cookie di sessione. Controlla gli aggiornamenti dei plugin, poiché molti hanno aggiunto il supporto per i flag di sicurezza in risposta ai cambiamenti del browser sull'applicazione di SameSite.

L'approccio a livello di server (Apache Header edit o Nginx proxy_cookie_flags) è la soluzione più affidabile, perché cattura tutti i cookie indipendentemente da quale plugin o script li imposta. Anche se un aggiornamento di un plugin rimuove i flag, la configurazione del tuo server li aggiunge nuovamente.

Considerazioni speciali per i cookie SameSite=None

Alcune funzionalità richiedono l'invio di cookie in contesti cross-site. Esempi comuni includono:

• Callback di provider di pagamento: Servizi come PayPal, Stripe o Mollie possono rinviare gli utenti al tuo sito dopo il pagamento. Se il tuo cookie di sessione usa SameSite=Strict, l'utente viene disconnesso dopo il reindirizzamento perché il browser non invia il cookie con la navigazione cross-site.
• Contenuti embedded (iframe): Se il tuo sito WordPress è embedded in un iframe su un dominio diverso, i cookie necessitano di SameSite=None; Secure per funzionare. Questo è rilevante per configurazioni WordPress headless o siti che offrono widget embeddabili.
• Flussi OAuth e SSO: Le implementazioni single sign-on che reindirizzano tramite provider di identità di terze parti possono necessitare di SameSite=None per il cookie di sessione durante il flusso di autenticazione.

Se hai bisogno di SameSite=None per cookie specifici mantenendo SameSite=Lax come predefinito, hai bisogno di una configurazione più mirata. In Apache:

<IfModule mod_headers.c>
    # Predefinito: aggiungi SameSite=Lax a tutti i cookie
    Header always edit Set-Cookie "^((?!.*SameSite).*)$" "$1; SameSite=Lax"

    # Override per cookie specifici che necessitano di accesso cross-site
    Header always edit Set-Cookie "(payment_session=.*)" "$1; SameSite=None; Secure"
</IfModule>

Aggiungere sicurezza ai cookie tramite un plugin WordPress

Se non hai accesso ai file di configurazione del server (comune con hosting WordPress gestito), puoi usare un plugin WordPress per aggiungere flag di sicurezza ai cookie. L'approccio plugin funziona agganciandosi al filtro wp_headers o usando la funzione header() di PHP per modificare gli header Set-Cookie prima che vengano inviati al browser:

function add_cookie_security_flags($headers) {
    // Questo influisce sugli header inviati da WordPress
    if (is_ssl()) {
        $headers['Set-Cookie'] = 'Secure; HttpOnly; SameSite=Lax';
    }
    return $headers;
}
add_filter('wp_headers', 'add_cookie_security_flags');

// Per la sicurezza dei cookie a livello PHP
function enforce_cookie_security() {
    if (is_ssl() && PHP_VERSION_ID >= 70300) {
        ini_set('session.cookie_secure', '1');
        ini_set('session.cookie_httponly', '1');
        ini_set('session.cookie_samesite', 'Lax');
    }
}
add_action('init', 'enforce_cookie_security', 1);

Questo approccio ha limitazioni. Influisce solo sui cookie impostati dopo che l'hook init di WordPress è stato attivato, e non può modificare i cookie impostati da JavaScript o da script esterni. L'approccio a livello di server è sempre più completo.

Verificare i flag di sicurezza dei cookie dopo aver applicato le correzioni

Dopo aver implementato le tue correzioni, è essenziale un test approfondito per confermare che tutto funzioni correttamente:

1. Cancella tutti i cookie del browser: Apri gli strumenti per sviluppatori del tuo browser, vai alla scheda Application (Chrome) o Storage (Firefox) ed elimina tutti i cookie per il tuo dominio. Questo ti consente di testare cookie freschi con i nuovi flag.
2. Visita il tuo sito ed effettua il login: Dopo aver effettuato il login, torna agli strumenti per sviluppatori e ispeziona ogni cookie. In Chrome, il pannello Application > Cookies mostra colonne per Secure, HttpOnly e SameSite. Ogni cookie di autenticazione dovrebbe mostrare un segno di spunta per Secure e HttpOnly, e visualizzare "Lax" per SameSite.
3. Testa flussi utente critici: Naviga attraverso la funzionalità principale del tuo sito: aggiungi articoli a un carrello (su WooCommerce), invia moduli, completa il processo di checkout e usa eventuali funzionalità di abbonamento. Le modifiche a SameSite possono occasionalmente rompere i flussi cross-site; quindi testa tutto ciò che coinvolge reindirizzamenti da servizi esterni.
4. Testa il login da link esterni: Inviati un'email di reset della password e clicca sul link. Se hai usato SameSite=Strict (sconsigliato), questo flusso potrebbe rompersi perché il cookie non viene inviato con la navigazione cross-site dal client email.
5. Esegui nuovamente InspectWP: Esegui una nuova scansione del tuo sito con InspectWP per confermare che tutti gli avvisi di sicurezza dei cookie siano stati risolti. InspectWP controlla ogni cookie individualmente, così puoi vedere esattamente quali cookie ora hanno i flag corretti.

Risolvere problemi comuni dopo aver abilitato i flag di sicurezza dei cookie

• Gli utenti vengono disconnessi dopo aver cliccato sui link email: Questo accade quando SameSite=Strict è impostato. Passa a SameSite=Lax, che permette i cookie nelle navigazioni di primo livello da siti esterni bloccando al contempo le richieste cross-site embedded.
• L'integrazione con il provider di pagamento non funziona: Alcuni provider di pagamento reindirizzano gli utenti attraverso il proprio dominio durante il checkout. Se il cookie di sessione non viene inviato dopo il reindirizzamento, l'utente perde il carrello o lo stato di login. Imposta il cookie della sessione di pagamento specificamente su SameSite=None; Secure, mentre gli altri cookie rimangono su SameSite=Lax.
• Il banner di consenso ai cookie continua ad apparire: Se il cookie del plugin di consenso ai cookie viene impostato senza il flag Secure e il tuo sito reindirizza da HTTP a HTTPS, il cookie impostato su HTTP non viene inviato su HTTPS, facendo riapparire il banner. Assicurati che il tuo sito funzioni interamente su HTTPS e che il cookie di consenso includa il flag Secure.
• Conflitti di caching: Alcuni plugin di caching memorizzano nella cache l'header Set-Cookie insieme al contenuto della pagina. Dopo aver applicato modifiche ai flag dei cookie a livello di server, svuota tutta la tua cache (sia la cache delle pagine che la object cache) per garantire che i nuovi header abbiano effetto.
• Flag cookie duplicati: Se vedi attributi come Secure; Secure o SameSite=Lax; SameSite=Lax nei tuoi cookie, più livelli stanno aggiungendo gli stessi flag. Controlla il tuo .htaccess, wp-config.php, impostazioni PHP ini e qualsiasi plugin di sicurezza per configurazioni sovrapposte. Usa l'approccio regex negative-lookahead in .htaccess per evitare duplicati.

Best practice per la sicurezza dei cookie in WordPress

• Usa sempre HTTPS: Il flag Secure è inutile senza HTTPS. Assicurati che il tuo intero sito si carichi tramite HTTPS, comprese tutte le risorse (immagini, script, fogli di stile). Usa la costante FORCE_SSL_ADMIN e considera un header HSTS per prevenire qualsiasi accesso HTTP.
• SameSite=Lax come predefinito: Questo fornisce una forte protezione CSRF senza rompere la navigazione normale. Usa SameSite=None solo per cookie specifici che realmente hanno bisogno di accesso cross-site, e usa SameSite=Strict solo se sei sicuro che nessuna navigazione esterna al tuo sito debba mantenere le sessioni.
• Applica i flag a livello di server: La configurazione a livello di server (Apache .htaccess o configurazione Nginx) cattura tutti i cookie indipendentemente dall'origine. Questo è più affidabile degli approcci a livello di plugin o PHP.
• Mantieni WordPress e i plugin aggiornati: Le versioni moderne del core di WordPress e della maggior parte dei plugin popolari impostano flag cookie corretti quando HTTPS è attivo. Mantenere tutto aggiornato riduce il numero di cookie insicuri che devi risolvere a livello di server.
• Audita i cookie regolarmente: Esegui periodicamente scansioni InspectWP per scoprire nuovi cookie introdotti da aggiornamenti dei plugin o nuove integrazioni. La sicurezza dei cookie non è una correzione una tantum; richiede attenzione continua man mano che il tuo sito evolve.
• Testa su più browser: Chrome, Firefox, Safari ed Edge gestiscono ciascuno gli attributi dei cookie in modo leggermente diverso. Chrome è il più rigoroso applicatore delle policy SameSite, mentre Safari ha la sua Intelligent Tracking Prevention che influisce sul comportamento dei cookie. Testa il tuo sito su tutti i principali browser dopo le modifiche.