CSP e HSTS: difendere un sito web dagli attacchi comuni

Perché CSP e HSTS contano davvero

Due intestazioni HTTP possono alzare parecchio il livello di sicurezza di un sito senza stravolgere il codice: Content Security Policy e HTTP Strict Transport Security. La prima limita da dove il browser può caricare script, immagini, font e altri contenuti; la seconda dice al browser di usare solo HTTPS per un certo dominio, evitando passaggi in chiaro e alcuni attacchi di downgrade.

Non sono una bacchetta magica. Non correggono un CMS vulnerabile, non sostituiscono aggiornamenti, backup e hardening lato server. Però, se configurate bene, riducono in modo concreto la superficie d’attacco. Il punto importante è questo: vanno introdotte con metodo, perché una policy troppo aggressiva può rompere il sito più velocemente di quanto lo protegga.

Content Security Policy: cosa fa e perché è utile

La CSP è una regola che il browser applica per decidere cosa è autorizzato a eseguire o caricare. Se un attaccante prova a iniettare uno script malevolo, il browser lo blocca se la policy non lo consente. È una difesa molto efficace contro molti casi di XSS, injection di risorse esterne e caricamenti non desiderati.

In pratica, la CSP ti permette di definire sorgenti affidabili per script, fogli di stile, immagini, font, connessioni AJAX, frame e altro. Più la policy è restrittiva, più riduci il rischio. Ma una policy restrittiva va costruita sui contenuti reali del sito, non copiata da un esempio generico trovato online.

Gli errori più comuni con CSP

Molti problemi nascono quando si imposta subito una policy troppo rigida. Gli errori tipici sono questi:

• bloccare script inline usati dal tema o da plugin;
• bloccare CDN esterne necessarie per font, immagini o librerie JS;
• dimenticare endpoint di analytics, chat, form o pagamenti;
• impostare una policy senza prima osservare cosa carica davvero la pagina.

Per questo la strada più sicura è partire in modalità osservazione, correggere, poi irrigidire. Non il contrario.

HSTS: cosa risolve e cosa non risolve

HSTS obbliga il browser a usare HTTPS per quel dominio dopo il primo contatto valido. Questo elimina molte situazioni in cui un utente prova ad aprire il sito in HTTP e viene intercettato, degradato o reindirizzato male. È particolarmente utile per siti con login, pannelli amministrativi, aree clienti e qualsiasi contenuto sensibile.

HSTS non installa il certificato, non sistema un sito che non risponde in TLS e non corregge redirect errati. Funziona bene solo se il sito è già completamente stabile in HTTPS, con certificato valido, catena corretta e redirect coerenti da HTTP a HTTPS.

Rischio da conoscere prima di attivare HSTS

Una volta che il browser memorizza HSTS, forzare HTTP diventa difficile anche per l’utente. Se il certificato scade o il sito ha problemi TLS, il visitatore potrebbe non riuscire ad aprire il dominio. Per questo non bisogna attivare HSTS con leggerezza su un sito non ancora ben testato.

La regola pratica è semplice: prima verifica che HTTPS funzioni ovunque, poi abilita HSTS con un valore iniziale prudente, solo dopo aver controllato che non esistano sottodomini critici senza TLS.

Approccio consigliato: prima osservare, poi irrigidire

La sequenza più sicura è questa: inventario, monitoraggio, correzione, enforcement. In altre parole, prima osservi cosa carica il sito, poi elimini le dipendenze inutili, infine fai rispettare la policy.

Per CSP, conviene iniziare con una modalità di segnalazione, se il tuo stack la supporta, così il browser invia report sulle violazioni senza rompere la pagina. Questo ti permette di vedere quali risorse verrebbero bloccate prima di passare alla modalità di blocco reale.

Per HSTS, conviene partire con un max-age contenuto e aumentarlo gradualmente. Se il sito è complesso, il rollout graduale è molto più sicuro di una attivazione aggressiva immediata.

Esempio di configurazione CSP di base

Un sito semplice, senza script esterni particolari, può partire da una policy molto essenziale. L’obiettivo non è essere perfetti al primo colpo, ma fare un primo passo che già riduca il rischio.

Content-Security-Policy: default-src 'self'; img-src 'self' data:; style-src 'self' 'unsafe-inline'; script-src 'self'; font-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self';

Questa configurazione è solo un punto di partenza. In molti siti reali dovrai aggiungere domini esterni per CDN, servizi video, mappe, analytics o altre integrazioni. Il consiglio è annotare ogni eccezione, chiederti se serve davvero e rimuovere ciò che non è indispensabile.

Un dettaglio importante: la presenza di 'unsafe-inline' in style-src è spesso un compromesso iniziale. Per gli script, invece, è meglio evitare questa scorciatoia quando possibile, perché indebolisce molto la protezione. Se il sito usa script inline, valuta nonce o hash, che sono soluzioni più pulite.

Esempio di configurazione HSTS di base

Per HSTS, una configurazione iniziale prudente può essere questa:

Strict-Transport-Security: max-age=86400; includeSubDomains

Un max-age di 86400 secondi equivale a un giorno. È un valore utile per testare la stabilità senza legare il browser per mesi. Solo dopo aver verificato che tutto funzioni correttamente puoi aumentare gradualmente la durata, ad esempio a una settimana, poi a un mese, poi a periodi più lunghi.

Il parametro includeSubDomains va usato solo se sei sicuro che anche i sottodomini siano in HTTPS. Se hai sottodomini vecchi, servizi interni o host non ancora pronti per TLS, meglio non inserirlo fino a quando l’ambiente non è allineato.

Dove si configurano su Apache, Nginx e pannelli hosting

Su Apache, le intestazioni si impostano spesso nel virtual host o nel file di configurazione del sito, oppure tramite .htaccess se il provider lo consente. Su Nginx, la configurazione va nel blocco del server o nel reverse proxy. Nei pannelli come cPanel, Plesk e FastPanel, spesso trovi una sezione dedicata alle intestazioni o ai template del virtual host.

Quando possibile, preferisci configurarle nel server virtual host o nel pannello, non nel codice applicativo. Così separi la sicurezza dalla logica del sito e riduci il rischio di perdere la configurazione durante un aggiornamento del CMS.

Se il sito è su WordPress, puoi usare plugin dedicati alle security headers, ma solo come soluzione rapida o temporanea. Per un ambiente stabile, la gestione lato web server resta più pulita e controllabile.

Verifiche pratiche prima di andare in produzione

Prima di pubblicare CSP e HSTS, fai controlli mirati. Non limitarti a vedere se la home si apre: serve verificare login, form, area amministrativa, caricamento immagini, font, script, embed e percorsi secondari.

1. Apri il sito in una finestra privata e controlla la console del browser: l’obiettivo è non avere errori di CSP non previsti.
2. Verifica il certificato HTTPS e i redirect: da HTTP a HTTPS deve esserci un percorso unico e pulito, senza catene inutili.
3. Controlla che i sottodomini importanti siano già pronti per HSTS, soprattutto se pensi di usare includeSubDomains.

Se trovi violazioni CSP, non disattivare tutto. Correggi una dipendenza alla volta, aggiornando la policy con criterio. La disciplina qui vale più della fretta.

Come leggere gli errori nel browser

Il browser è il tuo primo strumento di diagnosi. In console vedrai messaggi del tipo “Refused to load” o “Refused to execute” quando una risorsa viola la policy. Questi messaggi sono preziosi perché indicano esattamente cosa è stato bloccato e da quale direttiva dipende il blocco.

Se invece il sito non mostra più elementi grafici o funzioni interattive, il problema spesso è una direttiva troppo stretta su script-src, style-src, img-src o connect-src. Il metodo corretto è mappare l’errore, capire se la risorsa è davvero necessaria e solo dopo autorizzarla.

Una policy buona è una policy che invecchia bene

Le integrazioni cambiano: oggi usi una CDN, domani aggiungi una libreria, dopodomani rimuovi un widget. Per questo la CSP va rivista periodicamente, non impostata una volta e dimenticata. Una policy troppo permissiva col tempo perde valore; una troppo rigida diventa un ostacolo operativo.

La scelta matura è tenere la policy essenziale, documentare ogni eccezione e togliere ciò che non serve più. Se il sito cresce, conviene introdurre un processo semplice: ogni nuova dipendenza esterna deve essere giustificata, testata e registrata.

Buone pratiche di sicurezza da affiancare

CSP e HSTS funzionano meglio se accompagnati da altre misure minime:

• aggiornamenti regolari di CMS, plugin, temi e librerie;
• backup verificati e ripristinabili;
• permessi file e directory corretti;
• autenticazione forte per gli account amministrativi;
• monitoraggio dei log web e degli errori TLS;
• eliminazione dei componenti non usati.

In un sito esposto su Internet, la sicurezza non è mai una singola opzione. È un insieme di piccoli controlli coerenti che riducono il margine di errore.

Checklist operativa essenziale

1. Verifica che HTTPS sia stabile su dominio principale e sottodomini rilevanti.
2. Introduci CSP in modalità osservazione o con policy minima, poi correggi le violazioni.
3. Attiva HSTS con un valore prudente e aumenta la durata solo dopo test completi.
4. Controlla console browser, redirect, certificato e compatibilità con plugin o integrazioni esterne.
5. Documenta le eccezioni e rivedile periodicamente per evitare accumuli di permissività.

Conclusione pratica

CSP e HSTS non sono decorazioni da sicurezza: sono due barriere reali che possono bloccare classi intere di problemi prima che arrivino all’utente. La differenza la fa il metodo. Se parti da un inventario delle dipendenze, fai verifiche mirate e allarghi le restrizioni solo quando il sito è pronto, ottieni protezione concreta senza trasformare la configurazione in un boomerang.

Il principio da tenere fermo è questo: proteggere senza improvvisare. Una policy ben costruita è una difesa che resta utile nel tempo, non una firma di facciata. Quando serve, meglio una configurazione più semplice ma valida che una policy teoricamente perfetta e praticamente ingestibile.