Defaults.Exposed › Correzioni › Content-Security-Policy (CSP)

Come correggere Content-Security-Policy (CSP)

Una Content Security Policy è una regola di sicurezza che il tuo sito consegna al browser di ogni visitatore, dicendogli esattamente quale codice è autorizzato a eseguire. Senza, se qualcosa di malevolo finisce mai su una pagina — tramite un box commenti, un plugin violato, o uno script di terze parti — il browser lo eseguirà liberamente, incluso codice che ruba in silenzio i numeri di carta e le password dei tuoi clienti mentre li digitano, con il lucchetto ancora visibile.

In sintesi per la tua attività: Se il tuo sito viene mai manomesso, del codice malevolo può leggere i dati di carta di pagamento e di accesso dei tuoi clienti direttamente dal tuo stesso checkout mentre tutto sembra del tutto normale — lasciandoti con storni, richieste per frode, una violazione dei dati da segnalare, e un fallimento di controllo che gli uffici sicurezza dei clienti più grandi usano per bloccare o uccidere un affare.

Cosa può costarti

• Del codice nascosto si insinua in una delle tue pagine e copia in silenzio ogni numero di carta e password che i tuoi clienti inseriscono al checkout, inviandolo a un attaccante mentre il tuo sito sembra del tutto normale — lo scopri solo quando arrivano i reclami per frode.
• Un truffatore piazza un finto modulo «paga qui» sul tuo sito reale che cattura i pagamenti sul proprio conto; i clienti pensano di aver pagato te, danno la colpa a te quando la merce non arriva mai, e rivogliono i loro soldi.
• L'ufficio sicurezza di un cliente più grande scansiona il tuo sito, vede che questa protezione basilare è disattivata, e la segnala — bloccando o facendoti perdere il contratto finché non dimostri che è stato sistemato.
• Una violazione ricondotta a una salvaguardia standard mancante diventa un incidente da segnalare: domande dell'autorità di regolamentazione, notifiche ai clienti, e un colpo alla reputazione che costa molto più della correzione gratuita.

Perché è importante. Il lucchetto dimostra che la connessione al tuo sito è privata, ma non fa nulla per controllare quale codice viene eseguito una volta che un visitatore è sulla pagina. Una Content Security Policy è la salvaguardia che lo fa — dice ai browser di ignorare qualsiasi script che non provenga da una fonte di cui ti fidi, così che un singolo campo, annuncio o plugin manomesso non possa essere trasformato in uno strumento per rubare denaro e dati ai tuoi clienti. È un controllo valutato sulla tua scorecard, del valore di punti reali, e una delle prime cose che una revisione di sicurezza professionale cerca.

Cos’è, in parole semplici

Quando qualcuno visita il tuo sito, il suo browser scarica la tua pagina ed esegue qualunque codice ci sia sopra — gli script che fanno scendere i menu, funzionare i pulsanti, inviare i moduli di pagamento, e così via. Per impostazione predefinita, il browser si fida di tutto. Non ha modo di sapere quale codice è davvero tuo e quale è stato infilato da qualcun altro.

Una Content Security Policy (spesso abbreviata in CSP) è un breve elenco di regole che il tuo sito allega a ogni pagina, dicendo al browser: «esegui solo codice dalle fonti che ho approvato, e rifiuta tutto il resto». È la differenza tra una discoteca che fa entrare chiunque e una con una lista di invitati all’ingresso.

Il motivo per cui questo conta così tanto è che i siti vengono manomessi di continuo — non sempre violando il tuo server, ma attraverso le porte sul retro che la maggior parte dei siti lascia aperte: un campo commenti, una casella di ricerca, un plugin non aggiornato, uno script di terze parti per annunci o statistiche, o un widget di chat. Se un attaccante riesce a far finire anche una sola riga del proprio codice su una delle tue pagine, il browser la esegue come se fosse tua. Da lì può leggere tutto ciò che i tuoi clienti digitano — numeri di carta, password, indirizzi — e inviarlo in silenzio altrove. Una Content Security Policy chiude quella porta rifiutandosi di eseguire qualsiasi cosa da una fonte che non hai approvato.

Quanto può costarti

Non è astratto. L’attacco che una Content Security Policy previene — codice iniettato in una pagina che ruba dati ai tuoi stessi clienti — è dietro alcune delle più grandi violazioni di skimming di carte mai registrate. Ecco come tende a svilupparsi per un’azienda normale:

• Lo skimmer invisibile del checkout. Un attaccante infila qualche riga di codice nella tua pagina di checkout tramite un plugin vulnerabile o uno script di terze parti compromesso. Ogni numero di carta, nome e CVV che i tuoi clienti digitano viene copiato e inviato all’attaccante in tempo reale. Il tuo sito appare e funziona alla perfezione; il lucchetto c’è. Lo scopri settimane dopo, quando il tuo provider di pagamenti chiama per un gruppo di segnalazioni di frode che risalgono tutte al tuo negozio. Ora affronti storni, un audit di sicurezza forzato, la possibile perdita dei diritti di elaborazione delle carte, e una violazione che potresti essere legalmente tenuto a segnalare.

• Il finto modulo di pagamento. Un truffatore inietta un convincente box «paga qui» sul tuo sito reale. I clienti inseriscono i loro dati fidandosi del tuo marchio; il denaro e i dati vanno all’attaccante. I clienti danno la colpa a te — e non hanno torto, perché è successo sul tuo sito.

• Il contratto perso. L’ufficio sicurezza di un potenziale cliente più grande fa una scansione automatica del tuo sito come parte della due diligence sui fornitori. Una Content Security Policy mancante compare subito come lacuna ad alta severità. Per un revisore di acquisti o sicurezza, quella singola salvaguardia mancante significa «questo fornitore non fa le basi» — e l’affare si blocca mentre chiedono la sistemazione, o va in silenzio a un concorrente che ha superato il controllo.

• La violazione da segnalare. Quando una violazione dei dati viene ricondotta a una salvaguardia standard, gratuita e mancante, smette di essere sfortuna e comincia a sembrare negligenza. Questo cambia le domande dell’autorità di regolamentazione, l’obbligo di notifica ai clienti, e il costo — sia la sanzione sia il danno reputazionale, che resta a lungo dopo che l’incidente è chiuso.

• L’annuncio o widget compromesso. Molti siti caricano codice da parti esterne — reti pubblicitarie, font, chat di assistenza, statistiche. Se anche solo una di queste viene violata, il codice malevolo entra dritto nelle tue pagine. Una Content Security Policy limita il raggio dell’esplosione permettendo solo le specifiche fonti esterne di cui ti fidi, così che la violazione di un fornitore non diventi automaticamente la tua.

Cos’è davvero (il dettaglio)

Una Content Security Policy viene consegnata come una singola intestazione di risposta HTTP — una riga che il tuo server web invia con ogni pagina. Il suo valore è un insieme di direttive, ciascuna che nomina un tipo di contenuto e le fonti permesse per esso. Per esempio:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self'

In parole semplici, significa: per impostazione predefinita carica solo cose dal mio stesso sito; esegui script solo dal mio stesso sito; non permettere vecchi plugin; e non lasciare che altri siti incorporino il mio in un frame.

Com’è fatto un «buono». Il nostro controllo non cerca solo la presenza dell’intestazione — legge la policy direttiva per direttiva e valuta quanto sia davvero forte, come farebbe un revisore di sicurezza. Una policy forte:

• Imposta una base restrittiva (default-src 'self') e la allarga solo per le specifiche terze parti fidate che usi davvero.
• Evita le scappatoie. Non usa 'unsafe-inline' o 'unsafe-eval' per gli script, e non usa fonti jolly (*) o di solo schema (come https:) per gli script — queste riaprono di fatto la porta che la policy dovrebbe chiudere. Dove gli script inline sono davvero necessari, usa un nonce o un hash così che venga eseguito solo il tuo specifico codice approvato.
• Blinda l’incorporamento in frame con frame-ancestors 'self' (che blocca anche l’attacco «incorpora il tuo sito per ingannare i tuoi clienti») e disabilita i plugin legacy con object-src 'none'.
• È di imposizione, non report-only. Un’intestazione Content-Security-Policy-Report-Only osserva soltanto; non fornisce alcuna protezione in esecuzione. Il nostro controllo le dà una piccola frazione del credito e non la registra mai come superamento. Sei protetto solo una volta che la policy è di imposizione.

Una policy che esiste ma si appoggia a 'unsafe-inline', 'unsafe-eval', o a jolly otterrà comunque un punteggio scarso — perché in pratica fornisce poca protezione reale. L’obiettivo è una policy stretta, non una policy qualsiasi.

Come sistemarlo (gratis, ~1-2 ore)

Passa questo alla tua persona IT o a chi gestisce il tuo sito — la correzione in sé è completamente gratuita. Facciamo pagare solo il monitoraggio nel tempo, perché resti in posizione e resti corretta; attivarla non costa nulla. Il motivo per cui richiede un’ora o due invece di pochi minuti è l’attento passo di prova che impedisce di bloccare per sbaglio parti del tuo stesso sito.

1. Parti in modalità report-only — non imporre ancora. Aggiungi un’intestazione di risposta Content-Security-Policy-Report-Only. Questa osserva e registra ciò che verrebbe bloccato senza bloccare effettivamente nulla, così il sito in produzione continua a funzionare mentre impari da cosa dipende davvero ogni pagina. (Importante: il report-only da solo non dà alcuna protezione ai visitatori — è solo il primo passo sicuro.)

2. Costruisci la policy da ciò che il tuo sito usa davvero. Esamina i report per trovare ogni fonte legittima di script, stili, font e immagini — il tuo dominio, le tue statistiche, il tuo provider di pagamenti, il tuo host dei font, il tuo widget di chat — ed elencale come fonti permesse. Un solido punto di partenza è default-src 'self' più voci esplicite per le terze parti fidate che usi davvero.

3. Evita le scappatoie che vanificano tutto il senso. Stai alla larga da 'unsafe-inline' e 'unsafe-eval' per gli script, ed evita fonti jolly come * e schemi nudi come https: per gli script — questi riaprono esattamente la lacuna che la policy dovrebbe chiudere. Dove gli script inline sono inevitabili, usa un nonce o un hash così che venga eseguito solo il tuo specifico codice approvato.

4. Blinda incorporamento in frame e plugin. Aggiungi frame-ancestors 'self' (che impedisce anche ad altri siti di incorporare il tuo per ingannare i tuoi clienti, e soddisfa il relativo controllo sul clickjacking) e object-src 'none' per bloccare i vecchi attacchi basati su plugin.

5. Passa da report-only a imposizione. Una volta che i report sono puliti e il sito funziona, cambia il nome dell’intestazione da Content-Security-Policy-Report-Only a Content-Security-Policy. Questo è il passo che davvero fornisce protezione — una policy in sola report-only non lo fa, e non supererà il controllo.

   Dove impostare l’intestazione dipende dalla tua piattaforma:

   • Cloudflare: Rules → Transform Rules → Modify Response Header → imposta Content-Security-Policy. (Puoi usare Cloudflare anche per la prova report-only.)
   • Nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';" always;
   • Apache: Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';"
   • IIS (web.config): aggiungi un’intestazione di risposta HTTP personalizzata di nome Content-Security-Policy con la policy come valore.
   • Google Workspace / Microsoft 365: questi gestiscono la tua email, non il tuo sito pubblico, quindi la policy si imposta ovunque sia davvero ospitato il tuo sito (Cloudflare o il tuo host web qui sopra), non nella console admin della tua email.

6. Ricontrolla il tuo dominio per confermare che la policy ora risulti attivata e di imposizione, senza scappatoie che la indeboliscono.

Errori comuni

• Fermarsi a report-only. L’errore più comune in assoluto: una policy viene aggiunta in modalità report-only, tutti passano oltre, e il sito non è mai davvero protetto. Il report-only non blocca nulla. Devi passare all’imposizione.
• Ricorrere a 'unsafe-inline' per farlo «funzionare e basta». Quando la policy blocca uno script inline legittimo, la correzione rapida è permettere tutti gli script inline — ma questo riapre esattamente il buco che la policy doveva chiudere. Usa invece un nonce o un hash.
• Usare un jolly. Un * nudo (o https:) in script-src permette script da ovunque, il che significa che la policy non dà quasi nessuna protezione reale e otterrà comunque un punteggio basso.
• Dimenticare le fonti di terze parti. Imporre una policy rigorosa senza prima elencare i servizi esterni legittimi che usi (statistiche, font, widget di pagamento) può rompere parti del tuo stesso sito — che è esattamente perché esiste il passo di prova report-only.
• Impostarla solo sulla home. La policy deve coprire ogni pagina, specialmente le pagine di checkout, accesso e account — sono quelle che vale la pena attaccare.
• Trattarla come un sostituto del lucchetto. Una Content Security Policy e HTTPS/HSTS proteggono cose diverse. Li vuoi tutti; uno non copre per un altro.

FAQ