Script di terze parti non gestiti: un punto cieco per la sicurezza
Dall'analisi alla chat dal vivo e ai pulsanti di pagamento, quasi ogni sito web moderno esegue codice che proviene da fonti esterne al controllo diretto del proprietario del sito. Questi script di terze parti, comunemente chiamati tag, pixel, widget o embed, possono leggere ciò che appare su una pagina, raccogliere informazioni sui visitatori e persino modificare la pagina nel browser del visitatore. L'articolo di formazione sulla sicurezza di Sucuri pubblicato il 24 agosto 2026 spiega che, sebbene non tutti gli script esterni siano pericolosi, ognuno di essi aumenta la superficie di attacco di un sito web. Se il fornitore, l'account di hosting o la configurazione di uno di questi servizi viene compromesso, l'impatto può estendersi a ogni pagina che carica lo script.
Uno script di terze parti è codice JavaScript o di altro tipo incorporato in un sito ma caricato da un dominio al di fuori del controllo del proprietario del sito. Esempi comuni includono tag di analisi e pixel pubblicitari, contenitori di gestione tag, widget di chat dal vivo, mappe di calore e strumenti di registrazione delle sessioni, piattaforme di test A/B, pop-up di gestione del consenso, moduli incorporati, video, strumenti di pianificazione, integrazioni di pagamento e prevenzione delle frodi e librerie JavaScript servite da reti di distribuzione dei contenuti (CDN) esterne. Le revisioni dovrebbero considerare anche iframe, plugin, blocchi HTML personalizzati e integrazioni CMS che richiamano risorse esterne, perché ognuno di questi funziona in modo diverso e aggiunge un altro servizio che può influenzare il sito o i suoi visitatori.
Secondo OWASP, i tag di marketing e analisi possono leggere i dati da una pagina e inviarli a servizi esterni, mentre i gestori di tag decidono quali script vengono caricati e dove vanno i dati. Sucuri evidenzia quattro rischi in particolare. In primo luogo, il codice esterno può cambiare senza alcun aggiornamento del sito web. Un file ospitato sul sito cambia solo quando qualcuno modifica il sito, ma uno script ospitato esternamente può essere modificato alla fonte mentre l'URL rimane lo stesso. Se un fornitore, una CDN o un account viene compromesso, gli aggressori potrebbero iniziare a distribuire codice modificato a ogni sito web che carica quella risorsa. In secondo luogo, i gestori di tag concentrano l'accesso alla pubblicazione. Un singolo account di gestione tag compromesso potrebbe consentire a un aggressore di pubblicare codice su un intero sito web, e il pericolo cresce quando i team utilizzano credenziali condivise, concedono permessi eccessivi, saltano l'autenticazione a più fattori o lasciano l'accesso alla pubblicazione senza revisione. In terzo luogo, gli script dannosi possono imitare strumenti fidati. I ricercatori di Sucuri hanno documentato uno skimmer di carte di credito mascherato da tracker Facebook Pixel. La versione dannosa utilizzava nomi e formattazioni familiari ma sostituiva il dominio legittimo con una fonte controllata dall'aggressore, quindi prendeva di mira le pagine di checkout per catturare le informazioni di pagamento. Uno script può sembrare familiare senza essere legittimo, quindi il dominio, la fonte, il comportamento e il metodo di installazione sono tutti importanti. In quarto luogo, le pagine di pagamento affrontano conseguenze maggiori. Gli script lato browser sulle pagine di checkout possono interagire con i moduli di pagamento e le informazioni inserite dal cliente. I Requisiti PCI DSS 6.4.3 e 11.6.1 si concentrano sull'autorizzazione degli script delle pagine di pagamento, sul controllo della loro integrità, sul mantenimento di un inventario e sul monitoraggio delle modifiche non autorizzate. PCI SSC ha pubblicato ulteriori linee guida sull'e-skimming per questi requisiti nel 2025. Lo stesso principio si applica ai siti al di fuori dell'ambito PCI: le pagine sensibili dovrebbero caricare solo risorse note, necessarie e monitorate.
Chi è responsabile? Sucuri sostiene che i team del sito web, della sicurezza, dello sviluppo, del marketing, dell'e-commerce e dei contenuti condividono la responsabilità. I team tecnici possono valutare come funziona uno script e quali controlli offre, mentre i responsabili aziendali sanno perché è stato aggiunto, quale campagna o funzione supporta e se è ancora necessario. Ogni integrazione dovrebbe avere un proprietario interno designato. Senza uno, strumenti di campagne obsolete e account abbandonati possono rimanere collegati alla produzione molto tempo dopo che qualcuno li ha esaminati.
Per ridurre il rischio, Sucuri raccomanda di combinare una chiara proprietà, accessi limitati, pulizia di routine, controlli tecnici e monitoraggio rivolto ai visitatori. Inizia mantenendo un inventario di script e integrazioni. Documenta ogni servizio esterno approvato, inclusi il nome dello strumento e del fornitore, lo scopo aziendale, il proprietario interno, le pagine in cui viene caricato, i dati che raccoglie o elabora, come è stato installato, gli utenti con accesso amministrativo o di pubblicazione e la data di aggiunta con una data di revisione successiva. Confronta periodicamente questo inventario con il sito web live; qualsiasi script mancante nell'inventario dovrebbe essere investigato. Limita l'accesso e richiedi l'autenticazione a più fattori. Utilizza account individuali invece di credenziali condivise, segui il principio del minimo privilegio concedendo agli utenti solo i permessi necessari per il loro ruolo e mantieni i diritti di pubblicazione in produzione a un gruppo ristretto. Abilita l'autenticazione a più fattori per gestori di tag, piattaforme di analisi, account pubblicitari, dashboard CMS, account di hosting e altri servizi collegati. Rivedi l'accesso quando i dipendenti cambiano ruolo o terminano i rapporti con agenzie e fornitori. Tratta le modifiche ai tag come rilasci del sito web. Uno script aggiunto tramite una dashboard può influenzare i visitatori direttamente come il codice distribuito tramite un flusso di lavoro di sviluppo. Prima di pubblicare un tag, documenta il suo scopo, identifica le pagine e i dati interessati, testalo al di fuori della produzione se possibile, fai revisionare da un'altra persona autorizzata, annota l'editore e la data e mantieni un percorso di rollback. Carica ogni script solo dove è necessario. Un pixel di conversione per una campagna non deve essere eseguito su tutto il sito. Un'integrazione di checkout non dovrebbe apparire su post di blog non correlati e uno strumento di registrazione delle sessioni dovrebbe escludere le pagine di accesso, account, moduli e pagamento. Limitare dove uno script può essere eseguito riduce l'esposizione non necessaria dei dati e limita i danni se un'integrazione viene violata. Elimina strumenti e accessi scaduti. Le integrazioni temporanee spesso sopravvivono alle campagne che le hanno introdotte. Quando si ritira uno strumento, rimuovi i suoi script e tag, revoca le sue chiavi API e i token, elimina i webhook inutilizzati, rimuovi gli account dei fornitori e conferma che la risorsa non venga più caricata sul sito pubblico. Impostare una data di scadenza o revisione impedisce che la tecnologia temporanea diventi infrastruttura permanente.
I controlli lato browser possono aggiungere un ulteriore livello. Una Content Security Policy (CSP) limita le fonti da cui un browser è autorizzato a caricare script e altre risorse. Può ridurre l'impatto dell'iniezione di script non autorizzati ma richiede test approfonditi per evitare di bloccare funzioni legittime. La Subresource Integrity (SRI) consente a un browser di verificare che una risorsa esterna corrisponda a un hash crittografico previsto prima di caricarla. La SRI funziona meglio per file fissi, non per script di fornitori che cambiano frequentemente. Questi controlli dovrebbero supportare, non sostituire, la gestione degli accessi, l'applicazione di patch, il monitoraggio e la revisione dei fornitori. Infine, monitora il sito web che i visitatori ricevono effettivamente. Non fare affidamento solo sulla dashboard CMS o sui file del server. Rivedi le pagine importanti come visitatore non autenticato utilizzando dispositivi, browser e fonti di traffico diversi. Fai attenzione a domini esterni sconosciuti, tag HTML personalizzati inspiegabili, reindirizzamenti o pop-up inattesi, nuove richieste di verifica o download, modifiche al comportamento di checkout e moduli, script caricati su pagine non correlate e tag pubblicati al di fuori del processo normale. Alcuni script dannosi si attivano solo su determinate pagine o in specifiche condizioni del visitatore. Il monitoraggio della pagina renderizzata e dell'attività di rete del browser può catturarli, mentre una semplice revisione dei file li mancherebbe.
Se trovi uno script non autorizzato, rimuovere lo script visibile è solo il primo passo. Conserva dettagli come l'URL dello script, le pagine interessate, gli screenshot, la cronologia di pubblicazione e l'ora approssimativa in cui è iniziato il comportamento. Quindi indaga su come è stato introdotto: controlla gli account amministratore del CMS, gli utenti del gestore di tag e la cronologia delle versioni, i plugin, i temi, i campi di codice personalizzato, i file e i database del sito web, le credenziali di hosting e distribuzione, l'accesso SFTP e gli account dei fornitori, i token API e i webhook. Cambia le credenziali compromesse, revoca i token esposti, applica patch al software vulnerabile e scansiona l'intero ambiente alla ricerca di backdoor o malware aggiuntivi, perché un aggressore che ha ancora accesso potrebbe semplicemente ripristinare lo script. Se il codice è stato trovato su una pagina di checkout, un modulo di accesso, un modulo di contatto o qualsiasi pagina che gestisce dati sensibili, determina quali informazioni potrebbero essere state esposte e segnala l'incidente ai team legali, della privacy e della conformità ai pagamenti.
Sucuri è chiaro che i siti web non dovrebbero evitare tutti gli script di terze parti. Analisi, elaborazione dei pagamenti, supporto, accessibilità e strumenti di marketing offrono un valore reale. L'approccio migliore è ridurre gli script non necessari e insistere su una chiara proprietà, controlli di accesso e monitoraggio per le integrazioni che mantieni. Un web application firewall (WAF) può aiutare a bloccare gli attacchi che portano alla compromissione del sito web o all'iniezione di script, ma non può garantire che un account fornitore approvato o uno script ospitato esternamente rimanga affidabile. I controlli lato browser e la governance delle integrazioni sono ancora necessari. Eliminare uno script non autorizzato non risolve necessariamente il sito web, perché lo script potrebbe essere un sintomo di un account amministratore compromesso, un plugin vulnerabile, credenziali rubate, una voce di database dannosa o una backdoor persistente. Il percorso di accesso originale deve essere identificato e chiuso. Tratta ogni tag, pixel, widget ed embed come codice di produzione. Assegna un proprietario, documenta perché esiste, limita chi può modificarlo, limita dove viene eseguito e monitora ciò che i visitatori sperimentano realmente. Per i siti che girano su hosting WordPress gestito come AEU Hosting, i backup automatici e l'hardening della sicurezza forniscono una base, ma i passaggi di responsabilità sopra descritti devono ancora essere in atto.