No unsafe-inline

Content Security Policy (CSP) è uno standard di sicurezza informatica introdotto per prevenire cross-site scripting (XSS), clickjacking e altri attacchi di iniezione di codice risultanti dall’esecuzione di contenuti dannosi nel contesto di una pagina Web attendibile. Il cross-site scripting (XSS) è un tipo di vulnerabilità di sicurezza che può essere trovata in alcune applicazioni web. Gli attacchi XSS consentono agli aggressori di iniettare script lato client nelle pagine Web visualizzate da altri utenti. Una vulnerabilità di tipo cross-site scripting può essere utilizzata dagli aggressori per aggirare i controlli di accesso come il criterio della stessa origine (same-origin). Osservando il National Vulnerability Database gestito dal NIST statunitense, vengono segnalate più di 1100 (Novembre 2025) vulnerabilità comeXSS per temi e plugin di WordPress.

Mantenere aggiornato il tuo sito con le ultime versioni di plugin e temi è la prima linea di difesa per garantire la sicurezza del tuo sito.

La seconda cosa da fare è implementare una rigorosa politica di sicurezza dei contenuti (CSP).

Il problema principale

Il problema principale con le politiche di sicurezza dei contenuti implementate nel mondo reale è che sono troppo deboli per proteggere davvero il tuo sito e che molte di esse possono essere banalmente aggirate da un attaccante.

La soluzione proposta

I ricercatori di Google consigliano, invece della whitelist dell’intero host, di attivare i singoli script tramite un approccio CSP nonces. Inoltre, al fine di facilitare l’adozione di CSP basate sui nonce, hanno proposto la parola chiave ‘strict-dynamic’.

I problemi con la CSP in WordPress

1. Creazione manuale di una policy

   Di solito, un progetto WordPress è un mix di codice scritto da diversi autori che hanno contribuito al Core e/o hanno scritto plugin e temi. Se è possibile inserire nella whitelist ogni script esterno caricato da un <script src="">, la verità è che in un progetto WordPress puoi avere dozzine di quegli script inclusi nei tuoi plugin e calcolare un hash crittografico per ciascuno di essi da includere nell’intestazione CSP può essere un lavoro frustrante. Tuttavia, ci sono molte estensioni del browser e plugin di WordPress che possono aiutarti in questo lavoro.

2. Script inline

   Il core di WordPress e i plugin utilizzano script inline. Per questi script, puoi calcolare gli hash da inserire manualmente nella tua policy, solo se questi script non cambiano ad ogni caricamento della pagina. Sfortunatamente, questo non è molto comune in quanto è frequente includere valori di variabili calcolati lato server negli script inline. E questo significa che i tuoi script inline cambiano troppo frequentemente per aggiungere manualmente i loro hash alla tua policy. Questo accade comunemente quando gli script sono localizzati.

3. WordPress non ha API per implementare i nonce per la CSP

   Anche se è facile generare un nonce per ogni visualizzazione di pagina, questo nonce deve essere inserito in ogni tag di script utilizzato per incorporare gli script inline nella tua pagina come

   <script nonce="rAnd0m"> doWhatever(); </script>

   e nella tua direttiva script-src:

   script-src 'nonce-rAnd0m';

   E, naturalmente, un nonce deve essere univoco per ogni risposta HTTP.

4. Hash non sicuri / stili inline

   A volte, gli elementi HTML come immagini o pulsanti utilizzano gli attributi degli eventi HTML (onclick, onsubmit…) per consentire agli eventi di attivare azioni in un browser. Non è possibile utilizzare hash o nonce per gli script inclusi negli attributi dell’evento e, adottando una CSP restrittiva, è necessario riscrivere il codice utilizzando alternative più sicure o utilizzare ‘unsafe-hashes’. C’è lo stesso problema quando gli stili inline vengono utilizzati nei tag HTML:

   <h1 style="color:blue;text-align:center;">This is a heading</h1> <p style="color:red;">This is a paragraph.</p>

   I browser CSP di livello 2 potrebbero andare bene semplicemente inserendo l’hash nella tua direttiva style-src. Tuttavia, nell’autorizzare gli hash nell’attributo style dei CSS inline nei browser che supportano CSP Livello 3, potresti ricevere un errore come questo

   Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self' 'sha256-nMxMqdZhkHxz5vAuW/PAoLvECzzsmeAxD/BNwG15HuA='". Either the 'unsafe-inline' keyword, a hash ('sha256-nMxMqdZhkHxz5vAuW/PAoLvECzzsmeAxD/BNwG15HuA='), or a nonce ('nonce-...') is required to enable inline execution.

   Per consentire gli stili inline devi usare ‘unsafe-hashes’ nella tua direttiva style-src (che è, in effetti, una keyword insicura).

L’approccio di questo plugin

Questo plugin affronta questi problemi in questo modo.

1. Durante una fase di acquisizione, rileva gli script, gli stili e altri contenuti incorporati presenti nelle pagine del tuo sito e li archivia nel database.
2. Quindi devi aggiungere in whitelist questi contenuti dal pannello di amministrazione del plugin.
3. Il plugin utilizza l’apprendimento automatico per raggruppare gli script inline cercando di aggregare gli script generati dallo stesso codice lato server (PHP). Pertanto, puoi autorizzare un esempio di script per autorizzare tutti gli script che il classificatore prevede di etichettare in dei cluster aggiunti in whitelist.
4. Puoi scegliere di utilizzare gli hash per autorizzare script esterni (e il plugin ti consentirà di includere la Subresource Integrity nei tuoi <script> e nei <link>)
5. Puoi usare hash o nonce per autorizzare gli script in linea.
6. Puoi chiedere al plugin di riscrivere la tua pagina per non utilizzare gli attributi degli eventi (convertiti in uno script in linea) e gli stili in linea (convertiti in un CSS interno).
7. È possibile impostare uno o più endpoint di segnalazione delle violazioni.

Il plugin supporta installazioni multisito e ha molte (troppe) opzioni documentate nella guida in linea.

Creare una politica sulla sicurezza dei contenuti

Dopo l’attivazione del plug-in, vai al menu Impostazioni e cerca il sottomenu Impostazioni CSP. I passaggi che dovresti fare sono i seguenti.

1. Dalla scheda Strumenti, attiva la cattura dei tag e utilizza il tuo sito visitando tutte le pagine o facendole visitare dai tuoi utenti per un periodo molto lungo in base all’utilizzo del tuo sito (ore o giorni).
2. Dalla scheda Strumenti, eseguire il clustering dei dati nel database (può utilizzare molte risorse del server).
3. Vai alla scheda Regole di base e includi nelle direttive CSP i valori desiderati (aiutati con la tabella a fondo pagina).
4. Vai alla scheda degli script esterni, alla scheda degli script in linea e alla scheda degli script invocati dai gestori di eventi e autorizza l’esecuzione di tutti gli script legittimi presenti nelle pagine del tuo sito.
5. Lasciando attiva la cattura del tag, attiva il test della policy (in questa fase il plugin genererà alcune violazioni della policy temporanea utilizzata per registrare valori aggiuntivi da inserire nelle direttive della tua “content security policy”).
6. Dopo aver visitato nuovamente le pagine del tuo sito, disabilita l’acquisizione dei tag e ripeti i precedenti passaggi 2, 3 e 4.
7. Abilita la protezione del sito.

NB Quando aggiorni plugin o temi, se qualcosa non funziona correttamente nelle pagine del tuo sito, disattiva temporaneamente la protezione e ripeti i passaggi da 1 a 7.

Hook dei plugin

Filtri

• nunil_output_csp_headers_header_csp nunil_output_csp_headers_header_csp è disponibile dalla versione 1.2.3 e può essere utilizzato per modificare l’intestazione Content-Security-Policy prima che venga inviata al browser

• no_unsafe_inline_not_sri_sources no_unsafe_inline_not_sri_sources può essere utilizzato per modificare l’elenco delle risorse esterne che non supportano la SRI (Subresource Integrity)

• no_unsafe_inline_final_output no_unsafe_inline_final_output è un filtro interno utilizzato per manipolare l’output del processo di WordPress appena prima che l’output venga inviato al browser.

• no_unsafe_inline_meta_injector no_unsafe_inline_meta_injector è un hook di filtro interno utilizzato per iniettare meta http-equiv=’Content-Security-Policy’ se la variabile è impostata

Azioni

• nunil_upgrade Le funzioni agganciate a nunil_upgrade verranno eseguite quando il plug-in viene aggiornato

• nunil_output_csp_headers Le funzioni agganciate a nunil_output_csp_headers verranno eseguite quando il plug-in emette l’intestazione CSP della risposta HTTP

Codice e librerie

Questa versione del plugin utilizza: * per processare l’HTML: * ivopetkov/HTML5DOMDocument con PHP<8.4 e libxml<=2.13.09 * Masterminds\HTML5 con PHP<8.4 e libxml>2.13.09 * \Dom\HTMLDocument: Le nuove features ext-dom with HTML5 con PHP>8.4 * RubixML per il machine learning dalla versione 1.1.0 – PHP-ML è utilizzato nelle versioni 1.0.x; * opctim/php-nilsimsa per calcolare e confrontare i digest Nilsimsa.

Le funzioni per i log sono state prese da * perfectyorg/perfecty-push-wp, una cosa che dovresti realmente provare se vuoi implementare le notifiche Push sul tuo sito.

La lista completa delle dipendenze utilizzate in questo plugin può essere vista nel grafico delle dipendenze su GitHub.

Contributi, problemi, bug

Il codice del plugin è ospitato su un repository pubblico su GitHub. Vieni a trovarmi lì per aiutarmi e dare i tuoi suggerimenti.