Come funziona questo controllo
Questo controllo agisce solo se il tuo sito invia già un header Content-Security-Policy; se non lo invia, è lo scanner degli header a segnalarlo. Scanaris legge la policy completa e cerca le due parole che la svuotano: 'unsafe-inline', che permette di eseguire qualsiasi script o stile scritto direttamente nell'HTML, e 'unsafe-eval', che permette di trasformare testo in codice con eval e simili. Se ne compare una, apre un riscontro di severità bassa con la lista delle debolezze trovate. È bassa perché avere una CSP imperfetta è comunque meglio che non averla, ma la protezione contro l'iniezione di script, che è la ragione d'essere della CSP, resta quasi annullata.
Perché conta
Una CSP rigorosa fa sì che, anche se un attaccante riesce a infilare uno <script> nella tua pagina (tramite un commento non sanificato, un parametro riflesso o una libreria compromessa), il browser si rifiuti di eseguirlo. Con 'unsafe-inline' in script-src, quello script iniettato si esegue lo stesso: l'header c'è, il lucchetto sembra chiuso, ma la porta è aperta. Dove sta la parola conta: in script-src è grave; in style-src è un rischio molto minore che molti siti accettano per i loro stili inline.
Come sistemarlo
1. Nonce per gli script inline
Un nonce è un valore casuale diverso a ogni richiesta che metti nell'header e in ogni tag <script> legittimo. Il browser esegue solo gli script che portano quel valore; uno script iniettato non lo conosce.
Content-Security-Policy: script-src 'nonce-R4nd0m' 'strict-dynamic'; object-src 'none'; base-uri 'self'Next.js lo fa nel middleware, generando il nonce e passandolo all'header e ai componenti; Nuxt, con un plugin server che lo inietta in ogni risposta (è ciò che fa Scanaris); Express, con un middleware che lo salva in res.locals e lo stampa nei template.
2. Hash per gli script fissi
Se uno script inline non cambia mai, calcola il suo hash SHA-256 e mettilo nella policy: 'sha256-…'. Funziona per frammenti piccoli, come quello di un tag manager, senza montare i nonce.
3. Spostare il codice in file
I gestori onclick="…" e i blocchi di script nell'HTML sono la causa abituale del bisogno di 'unsafe-inline'. Spostali in file .js serviti dal tuo dominio e il bisogno sparisce.
4. Togliere unsafe-eval
Di solito lo richiede una libreria vecchia o una modalità di sviluppo di un framework finita in produzione. Controlla nella console del browser cosa lo richiede e aggiorna o sostituisci quel pezzo.
5. Pubblicare in modalità report
Pubblica prima la nuova policy come Content-Security-Policy-Report-Only con una direttiva report-to o report-uri verso un tuo endpoint. Per qualche giorno raccogli cosa bloccherebbe, aggiusta, e quando i report sono puliti passala all'header che blocca.
Verifica che sia sistemato
curl -sI https://tuodominio.com | grep -i "content-security-policy"In script-src non devono comparire né 'unsafe-inline' né 'unsafe-eval'. Poi naviga sul tuo sito con la console aperta: qualsiasi blocco compare lì con la direttiva che l'ha causato. La teoria completa è in header di sicurezza HTTP spiegati per umani.
Domande frequenti
Uso Tailwind o stili inline. Devo togliere unsafe-inline da style-src?
È auspicabile ma non urgente. Gli stili inline non eseguono codice. Dai priorità a script-src; una policy con 'unsafe-inline' solo in style-src protegge da ciò che conta.
Google Tag Manager o una chat di supporto mi obbligano ad allentare la policy.
Quasi tutti hanno documentazione CSP: accettano un nonce o pubblicano gli hash e i domini di cui hanno bisogno. Aggiungi le loro origini a script-src e connect-src invece di aprire tutto.
La CSP mi romperà il sito?
Solo se la passi a bloccare senza provare. Per questo esiste la modalità report: ti mostra cosa romperebbe senza romperlo.