Security Headers HTTP — Configurare CSP, HSTS e X-Frame per Siti che Non Vogliono Essere Hackerati

Il tuo sito è già in HTTPS, i form hanno CAPTCHA, le password sono hashate. Eppure qualcosa non torna. Il browser ti segnala warning sulla console: Content Security Policy mancante. Un cliente ti chiama perché il sito viene visualizzato dentro un iframe su un dominio che non conosci. Oppure, peggio, scopri che un attacco XSS ha iniettato codice malevolo nelle pagine prodotto. Succede quando gli HTTP security headers sono trascurati. Noi, di Meteora Web, li trattiamo come il lucchetto sulla porta di casa: se non lo metti, prima o poi qualcuno entra. In questa guida vediamo come configurare i tre header fondamentali — CSP, HSTS e X-Frame-Options — per proteggere qualsiasi sito web. E lo facciamo con esempi reali, codice funzionante e il nostro solito approccio: costi e benefici concreti.

Perché gli HTTP Security Headers Sono la Prima Difesa contro XSS e Clickjacking?

Immagina di affittare un negozio. Metti una bella insegna, arredi moderni, ma lasci la porta sul retro spalancata. È quello che succede quando pubblichi un sito senza security headers. Un attacco Cross-Site Scripting (XSS) o Clickjacking può bypassare tutte le altre difese se il browser non riceve istruzioni precise su cosa caricare e come comportarsi. Gli header HTTP sono istruzioni che il server invia al browser prima di qualsiasi contenuto della pagina. Senza di essi, il browser accetta qualsiasi script, qualsiasi iframe, qualsiasi connessione mista (HTTP/HTTPS) — un invito a nozze per gli attaccanti.

Esempio concreto: qualche mese fa abbiamo ereditato un e-commerce WooCommerce. Il cliente si lamentava di carrelli abbandonati e di una lentezza inspiegabile. Controllando i security headers, abbiamo scoperto che mancava completamente Content-Security-Policy. Risultato: il sito caricava script da fonti arbitrarie, incluso un minatore di criptovalute iniettato via plugin vulnerabile. Risolto con una CSP ben configurata, abbiamo bloccato lo script illecito e migliorato i tempi di caricamento del 30%. Il costo? Zero. Nessun nuovo plugin, nessun investimento. Solo configurazione.

Cosa fare subito:
Apri la console del browser sul tuo sito (F12 → Console). Se vedi messaggi rossi come "Refused to load the script... because it violates the following Content Security Policy directive...", significa che hai già una CSP, ma forse è troppo rigida. Se non vedi nulla, probabilmente non hai nessuna CSP. È il primo segnale d'allarme.

Come Funziona Content-Security-Policy e Come Configurarla senza Rompere il Sito?

La CSP è il re degli header di sicurezza. Dice al browser: "Da queste fonti puoi caricare script, stili, immagini, font — da tutto il resto, no." Se un attaccante riesce a iniettare uno script malevolo, il browser lo blocca a prescindere. Ma una CSP troppo aggressiva rompe il sito (immagini che non caricano, script di analytics bloccati). Il trucco è bilanciare sicurezza e funzionalità.

Struttura di base di una CSP

Una direttiva CSP si compone di un tipo di risorsa (default-src, script-src, style-src, img-src, etc.) seguita da una o più origini consentite. Ecco un esempio per un sito WordPress con Google Analytics e jQuery da CDN:

# In Nginx, dentro server block
add_header Content-Security-Policy "
    default-src 'self';
    script-src 'self' https://www.googletagmanager.com https://ajax.googleapis.com 'unsafe-inline' 'unsafe-eval';
    style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
    img-src 'self' data: https://www.google-analytics.com https://www.googletagmanager.com;
    font-src 'self' https://fonts.gstatic.com;
    connect-src 'self' https://www.google-analytics.com;
    frame-src 'self' https://www.youtube.com;
    object-src 'none';
    base-uri 'self';
    form-action 'self';
";

Attenzione: 'unsafe-inline' e 'unsafe-eval' riducono la protezione. In molti siti WordPress sono necessari per i plugin, ma vanno limitati. Se puoi passare a script non inline (usando nonce o hash), la sicurezza sale vertiginosamente. Noi, di Meteora Web, in progetti Laravel o Vue usiamo nonce generati lato server per ogni richiesta — più complesso, ma molto più sicuro.

Passaggi pratici per configurare CSP su Nginx

1. Determina tutte le risorse esterne del tuo sito (script, stili, immagini, font, iframe, etc.). Usa gli strumenti sviluppatore → Network, filtra per i domini terzi.
2. Crea una policy iniziale in modalità report-only: Content-Security-Policy-Report-Only. In questo modo il browser segnala le violazioni ma non blocca nulla. Puoi raccogliere i report via un endpoint dedicato (es. report-uri.com).
3. Analizza i report per 1-2 settimane. Aggiungi le origini mancanti.
4. Passa alla modalità enforcement: Content-Security-Policy.
5. Ripeti periodicamente, specialmente dopo ogni aggiornamento di plugin o temi.

Esempio di configurazione su Apache (htaccess)

<IfModule mod_headers.c>
  Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://www.googletagmanager.com 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data: https://www.google-analytics.com; font-src 'self' https://fonts.gstatic.com; connect-src 'self'; frame-src 'self' https://www.youtube.com; object-src 'none'; base-uri 'self'; form-action 'self';"
</IfModule>

Come Attivare HSTS e Perché Non Dovresti Fare a Meno di HTTPS Strict Transport Security?

HSTS (HTTP Strict Transport Security) dice al browser: "Da ora in poi, connettiti sempre a questo dominio esclusivamente via HTTPS, anche se l'utente digita http://." Se non hai HSTS, un attacco man-in-the-middle (MITM) può intercettare la prima richiesta HTTP, reindirizzarti a una versione malevola del sito e rubare credenziali.

Configurazione HSTS — I Parametri Che Contano

L'header ha tre parametri principali:

• max-age: durata in secondi. Un valore comune per siti produttivi è 63072000 (2 anni).
• includeSubDomains: applica la regola anche a tutti i sottodomini (consigliato se usi, ad esempio, app.tuodominio.it).
• preload: se intendi candidare il dominio alle liste preload dei browser (Chrome, Firefox, etc.), aggiungi questo flag. Ma attenzione: una volta aggiunto al preload, in pratica è irreversibile per mesi. Assicurati di avere HTTPS su tutti i sottodomini e nessun errore.

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

Su Apache:

Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

Attenzione: Non attivare includeSubDomains se hai un sottodominio che non supporta HTTPS (es. vecchio blog separato). Potresti bloccare l'accesso a quel sottodominio. In tal caso, configura HSTS solo sul dominio principale, o prepara HTTPS su tutti i sottodomini prima.

Verifica che HSTS sia attivo

Usa lo strumento online hstspreload.org per testare il tuo dominio. Inserisci l'URL e vedrai se l'header è presente e se i parametri sono corretti. Puoi anche usare curl -I https://www.tuosito.it e controllare la riga strict-transport-security.

X-Frame-Options: Come Impedire che il Tuo Sito Venga Caricato in Iframe su Domini Esterni?

Il clickjacking è un attacco in cui un utente viene indotto a cliccare su un elemento invisibile di un iframe posizionato sopra un altro sito. Ad esempio, un iframe con il tuo form di login viene caricato su un sito di phishing, ma l'utente pensa di cliccare su un pulsante innocuo. L'header X-Frame-Options impedisce al browser di caricare la pagina in un iframe, tranne che da origini fidate.

Opzioni disponibili

• DENY: nessun iframe consentito. La scelta più sicura.
• SAMEORIGIN: consentito solo da iframe sullo stesso dominio. Utile se usi iframe tu stesso (es. per integrare una mappa o un modulo interno).
• ALLOW-FROM uri (deprecato in molti browser). Oggi meglio usare Content-Security-Policy frame-ancestors per controlli più granulari.

Configurazione su Nginx:

add_header X-Frame-Options "SAMEORIGIN" always;

Su Apache:

Header always set X-Frame-Options "SAMEORIGIN"

La variante moderna: Content-Security-Policy frame-ancestors

frame-ancestors è la direttiva CSP che sostituisce X-Frame-Options. Permette di specificare esattamente quali domini possono includere la tua pagina in un iframe, supporta wildcard e più origini. Esempio per consentire solo il tuo dominio e un partner fidato:

add_header Content-Security-Policy "frame-ancestors 'self' https://partner.com";

Noi, di Meteora Web, consigliamo di utilizzare frame-ancestors al posto di X-Frame-Options se il tuo pubblico usa browser moderni (tutti gli attuali), perché è più flessibile. Ma per massima compatibilità (vecchi browser), includi entrambi.

Come Testare e Monitorare gli Security Headers con Strumenti Gratuiti?

Non basta configurare: devi verificare che gli header siano inviati correttamente e che non vengano sovrascritti da CDN, reverse proxy o plugin. Ecco gli strumenti che usiamo noi quotidianamente:

• SecurityHeaders.com: fornisce un report completo per ogni header, con un voto da A a F. Punta ad A.
• Mozilla Observatory: simile, ma include anche test per vulnerabilità comuni.
• curl dalla riga di comando: curl -I https://tuosito.it | grep -i "content-security-policy\|strict-transport-security\|x-frame-options"
• Browser console: come detto, i warning CSP sono immediati.

Automatizza il monitoraggio: integra questi test nella tua CI/CD. Noi abbiamo un job GitHub Actions che ogni notte fa una richiesta HTTPS e controlla gli header. Se qualcosa cambia (ad esempio dopo un deploy), riceviamo una notifica. È un piccolo accorgimento che ha salvato più di un progetto da regressioni di sicurezza.

Cosa Fare Adesso: Checklist Operativa per Mettere in Sicurezza il Tuo Sito

Abbiamo visto teoria e configurazione. Ora passiamo all’azione. Ecco i passi concreti da eseguire oggi stesso:

1. Scarica il report di securityheaders.com per il tuo dominio. Identifica gli header mancanti o errati.
2. Configura HSTS con max-age di almeno 6 mesi (consigliato 2 anni), includi subdomain se sicuro, e verifica su hstspreload.org.
3. Imposta X-Frame-Options su SAMEORIGIN (o DENY se non usi iframe) e, in parallelo, aggiungi frame-ancestors 'self' nella CSP.
4. Costruisci una CSP in modalità report-only. Raccogli report per 1-2 settimane usando un endpoint gratis come report-uri.com. Aggiungi le origini mancanti, poi passa in enforcing.
5. Verifica che niente si sia rotto dopo la configurazione: naviga nelle pagine chiave (carrello, checkout, form) e controlla la console del browser per eventuali violazioni CSP.
6. Ripeti il test su securityheaders.com e punta ad A. Se ottieni B o C, correggi gli errori segnalati.

Noi di Meteora Web lo facciamo per ogni nuovo progetto, che sia un e-commerce in WooCommerce o una webapp in Laravel. I security headers non sono un extra: sono la base. Un cliente di un noto brand di abbigliamento che seguiamo ha risolto un problema di clickjacking su una pagina promozionale semplicemente aggiungendo X-Frame-Options SAMEORIGIN. Risultato: nessuna perdita di traffico, nessun danno reputazionale. Il costo? Zero. Il rischio evitato? Potenzialmente milioni di danni.

Per approfondire l'intero approccio alla sicurezza web, consulta la nostra guida pillar sulla sicurezza web per sviluppatori.