HTTP security headers WordPress: CSP, HSTS, X-Frame-Options e gli header che proteggono davvero

Gli HTTP security headers sono l'ultima linea di difesa del browser — e la maggior parte dei siti WordPress non li ha. Non perché siano difficili da configurare, ma perché nessuno ci pensa. I plugin di sicurezza non li gestiscono (lavorano a livello di PHP, non di server), e gli sviluppatori di temi non li configurano. Risultato: il sito è vulnerabile al clickjacking, al MIME sniffing, al downgrade HTTPS, e al XSS — tutte cose che un header di due righe nel .htaccess chiude.

Il primo header da attivare è HSTS — lo abbiamo trattato nell'articolo sul SSL, quindi non lo ripeto. Il secondo è X-Frame-Options, che impedisce al tuo sito di essere incorporato in un iframe di un altro sito (clickjacking). Il terzo è X-Content-Type-Options, che impedisce al browser di indovinare il MIME type dei file (MIME sniffing). Il quarto — il più potente e il più pericoloso — è Content-Security-Policy.

Gli header base (sicuri e senza rischi)

Gli header base si configurano in .htaccess su Apache o nel server block di Nginx. Sono sicuri perché non cambiano il comportamento del sito — aggiungono solo restrizioni che il browser rispetta:

# .htaccess — HTTP security headers base
<IfModule mod_headers.c>
    # Impedisci al browser di indovinare il MIME type
    Header always set X-Content-Type-Options "nosniff"

    # Impedisci al sito di essere incorporato in iframe (clickjacking)
    Header always set X-Frame-Options "SAMEORIGIN"

    # HSTS: forza HTTPS per 1 anno (aumenta gradualmente)
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

    # Referrer-Policy: invia solo l'origine, non il path completo
    Header always set Referrer-Policy "strict-origin-when-cross-origin"

    # Permissions-Policy: disabilita API non necessarie
    Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
</IfModule>

Content-Security-Policy: l'header più potente e più pericoloso

La CSP è l'header di sicurezza più potente che esista — e il più facile con cui rompere un sito. Una CSP ben configurata previene il XSS (Cross-Site Scripting) bloccando l'esecuzione di script non autorizzati. Una CSP mal configurata rompe JavaScript, CSS, immagini, e tutto quello che il sito carica da fonti esterne. La regola: mai attivare una CSP in produzione senza prima testarla in Report-Only mode.

La CSP in modalità Report-Only non blocca nulla — registra le violazioni nella console del browser. La usi per capire cosa la CSP bloccherebbe prima di attivarla davvero:

# .htaccess — CSP in modalità Report-Only (test, non blocca)
<IfModule mod_headers.c>
    Header always set Content-Security-Policy-Report-Only \
        "default-src 'self'; \
         script-src 'self' 'unsafe-inline' 'unsafe-eval' https://www.googletagmanager.com https://www.google-analytics.com; \
         style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; \
         font-src 'self' https://fonts.gstatic.com data:; \
         img-src 'self' data: https: blob:; \
         connect-src 'self' https://www.google-analytics.com; \
         frame-src 'self' https://www.youtube.com; \
         object-src 'none'; \
         base-uri 'self'; \
         form-action 'self';"
</IfModule>

# Dopo aver testato e corretto le violazioni,
# cambia Report-Only in CSP attiva:
# Header always set Content-Security-Policy "..."

La verifica: securityheaders.com e il test finale

Il modo più rapido di verificare i tuoi header è securityheaders.com — inserisci l'URL e ti restituisce un punteggio da F ad A+. Non è un punteggio SEO, è un punteggio di sicurezza del browser. Un sito con A+ è protetto da tutti gli attacchi che gli header possono fermare. Un sito con F è nudo. La maggior parte dei siti WordPress che vediamo ha F o D — non perché siano insicuri di base, ma perché non hanno configurato gli header.

# Verifica gli header di sicurezza con curl
curl -sI https://www.example.com | grep -iE \
  'strict-transport-security|x-content-type|x-frame|content-security|referrer|permissions'

# Output atteso (se configurati):
# strict-transport-security: max-age=31536000; includeSubDomains
# x-content-type-options: nosniff
# x-frame-options: SAMEORIGIN
# content-security-policy: default-src 'self'; ...
# referrer-policy: strict-origin-when-cross-origin
# permissions-policy: geolocation=(), microphone=(), camera=()

# Test completo con securityheaders.com API
curl -s 'https://api.securityheaders.com/?q=https://www.example.com&followRedirects=on' | python -m json.tool

Gli HTTP security headers sono l'unico intervento di sicurezza che protegge il browser dell'utente — non il server. Il WAF protegge il server, il backup protegge i dati, ma gli header proteggono l'utente mentre naviga. E dato che l'utente è l'anello più debole (clickjacking, XSS, downgrade), gli header sono l'intervento con il ritorno più immediato per la sicurezza percepita e reale. Cinque righe di .htaccess, punteggio da F ad A+. Non c'è motivo di non farlo.