Gli script di terze parti possono mettere a rischio ogni pagina di un sito web

Ogni sito che utilizza analytics, pubblicità, chat dal vivo o un widget di pagamento carica script di terze parti: pezzi di codice che compaiono sulla pagina ma vengono recuperati da un dominio che il proprietario del sito non controlla. Un post sul blog di Sucuri pubblicato il 24 agosto 2026 illustra come quei tag, pixel, widget ed embed aggiungano rischio a un sito web, perché un singolo account fornitore compromesso può raggiungere tutte le pagine in una volta, e cosa possono fare i proprietari dei siti e i loro team per tenere sotto controllo l'esposizione. Sucuri è un'azienda di sicurezza per siti web, e il post si basa sul lavoro diretto dei suoi ricercatori sugli incidenti oltre che sui requisiti pubblicati in materia di sicurezza dei pagamenti.

Sucuri definisce uno script di terze parti come JavaScript o altro codice incorporato in una pagina e caricato da un servizio o dominio al di fuori del controllo diretto del proprietario del sito. Gli esempi elencati sono il normale arredamento di un sito moderno: tag di analytics e pixel pubblicitari, contenitori di tag management, widget di chat dal vivo e assistenza clienti, strumenti di heatmap e registrazione delle sessioni, piattaforme di A/B testing e personalizzazione, strumenti di gestione del consenso, moduli, video e strumenti di pianificazione incorporati, integrazioni di pagamento, prevenzione frodi e social media, e librerie JavaScript ospitate su content delivery network (CDN, reti di server che distribuiscono file per molti siti) esterne. Il post aggiunge che le revisioni di sicurezza dovrebbero coprire anche gli iframe (una pagina incorporata dentro un'altra), i plugin, i blocchi HTML personalizzati e le integrazioni con il content management system (CMS) che richiamano risorse esterne. Ognuno di questi si comporta in modo diverso, e ognuno aggiunge un altro servizio che può influire sul sito o sui suoi visitatori.

Questo rende gli script di terze parti un problema di sicurezza? La risposta di Sucuri è condizionata: non automaticamente, ma sì quando uno script ha più accesso di quanto gli serva, è gestito male, proviene da una fonte compromessa, o continua a funzionare molto tempo dopo che la ragione commerciale per cui esisteva è scomparsa. Il post cita OWASP, la comunità aperta che pubblica linee guida sulla sicurezza delle applicazioni web, che osserva come i tag di marketing e analytics possano leggere dati dalla pagina e inviarli a servizi esterni. I tag manager fanno ancora di più: decidono quali script vengono caricati, quali informazioni ricevono quegli script e dove finiscono i dati.

Quattro rischi ricevono particolare attenzione. Il primo è che il codice esterno può cambiare senza un aggiornamento del sito. Un file ospitato sul tuo server normalmente cambia solo quando qualcuno aggiorna il sito, ma uno script ospitato esternamente può cambiare alla sua origine mentre il suo indirizzo e la sua posizione nella pagina restano esattamente gli stessi. È questo che permette ai fornitori di continuare a migliorare il loro servizio senza che i clienti ridistribuiscano nulla, ed è anche il meccanismo con cui un fornitore, una CDN o un account compromesso potrebbe iniziare a distribuire codice modificato a ogni sito web che carica la risorsa.

Il secondo rischio è che i tag manager concentrano il potere di pubblicazione. Permettono ai team di marketing e analytics di aggiungere script senza toccare direttamente il sito, il che è comodo ma crea un punto di controllo di alto valore. Sucuri sottolinea che un solo account di tag management compromesso potrebbe permettere a un attaccante di pubblicare codice su un intero sito web, e che il pericolo cresce con credenziali condivise, permessi eccessivi, autenticazione a più fattori (MFA, un secondo passaggio di login oltre alla password) assente e accesso alla pubblicazione che nessuno controlla.

Il terzo rischio è l'imitazione. Gli amministratori si aspettano di vedere tag di analytics e pixel di tracciamento familiari, e gli attaccanti contano su questo. I ricercatori di Sucuri hanno documentato uno skimmer di carte di credito camuffato da tracker Facebook Pixel: la versione malevola usava nomi e formattazione familiari, sostituiva il dominio legittimo con una fonte controllata dall'attaccante, prendeva di mira le pagine di checkout e catturava le informazioni di pagamento. Uno script può quindi sembrare familiare senza essere legittimo, ed è per questo che il dominio, la fonte, il comportamento e il modo in cui uno script è stato installato contano tutti.

Il quarto rischio è la conseguenza più pesante sulle pagine di pagamento, perché gli script lato browser presenti lì possono interagire con i moduli di pagamento e con i dati che i clienti digitano al loro interno. I requisiti 6.4.3 e 11.6.1 del PCI DSS (lo standard di sicurezza dei dati del settore delle carte di pagamento) riguardano l'autorizzazione degli script su una pagina di pagamento, la verifica della loro integrità, la tenuta di un inventario e il monitoraggio di modifiche non autorizzate, e il PCI Security Standards Council ha pubblicato nel 2025 ulteriori linee guida sull'e-skimming per quei requisiti. Il punto di Sucuri è che i siti al di fuori dell'ambito del PCI DSS possono applicare lo stesso principio: le pagine sensibili dovrebbero caricare solo risorse note, necessarie e sorvegliate.

La responsabilità è condivisa. I team del sito web, della sicurezza, dello sviluppo, del marketing, dell'e-commerce e dei contenuti hanno tutti una parte: i team tecnici possono valutare come funziona uno script e quali controlli esistono, mentre i titolari delle attività tendono a sapere perché è stato aggiunto uno strumento, quale campagna supporta, chi gestisce il rapporto con il fornitore e se è ancora necessario. Ogni integrazione dovrebbe avere un responsabile interno nominato, perché senza di esso gli strumenti di campagne obsolete e gli account abbandonati possono restare collegati alla produzione molto tempo dopo che qualcuno li ha guardati l'ultima volta.

Per ridurre il rischio, Sucuri raccomanda una chiara attribuzione di responsabilità, accessi limitati, pulizia regolare, controlli tecnici e monitoraggio di ciò che i visitatori vedono effettivamente. Tieni un inventario di ogni servizio esterno approvato che può influire sul sito, registrando il nome dello strumento e del fornitore, il suo scopo commerciale, il suo responsabile interno, le pagine su cui viene caricato, i dati che raccoglie o elabora, come è stato installato, chi detiene l'accesso amministrativo o di pubblicazione, e la data in cui è stato aggiunto con una data di prossima revisione. Confronta quell'elenco con il sito live regolarmente e indaga su qualsiasi cosa presente sul sito ma assente dall'inventario. Usa account individuali invece di quelli condivisi, concedi alle persone solo i permessi di cui il loro ruolo ha bisogno, mantieni i diritti di pubblicazione in produzione a un piccolo gruppo, e attiva la MFA per tag manager, piattaforme di analytics e pubblicità, dashboard CMS, account di hosting e altri servizi collegati, rivedendo gli accessi ogni volta che qualcuno cambia ruolo o termina un rapporto con un fornitore.

Sucuri sostiene inoltre che un tag modificato da una dashboard merita lo stesso trattamento di un rilascio di codice, perché influisce sui visitatori altrettanto direttamente. Prima di pubblicare un tag, il post suggerisce di documentarne lo scopo, identificare le pagine e i dati interessati, testarlo fuori dalla produzione dove possibile, farlo rivedere da una seconda persona autorizzata, annotare chi lo ha pubblicato e quando, e mantenere un percorso di rollback. Quel processo non deve essere lento, solo visibile e responsabile. Gli script dovrebbero caricarsi solo dove sono necessari: un pixel di conversione per una campagna raramente deve funzionare su tutto il sito, un'integrazione di checkout non dovrebbe comparire su post di blog non correlati, e uno strumento di registrazione delle sessioni potrebbe dover escludere pagine di login, account, moduli e pagamento. Quando uno strumento viene dismesso, il post consiglia di rimuovere i suoi script e tag, revocare le sue chiavi API e i suoi token, eliminare i webhook inutilizzati, rimuovere gli account dei fornitori e confermare che la risorsa non venga più caricata sul sito pubblico, con una data di revisione o scadenza per impedire che strumenti temporanei diventino infrastruttura permanente.

I controlli lato browser possono aiutare, entro certi limiti. Una Content Security Policy (CSP) dice al browser da quali fonti può caricare script e altre risorse, il che può ridurre l'impatto di un'iniezione di script non autorizzata ma richiede test approfonditi per non bloccare funzioni legittime. Subresource Integrity (SRI) permette a un browser di verificare una risorsa esterna rispetto a un'impronta crittografica attesa prima di caricarla, ed è più adatto a file fissi che a script di fornitori che cambiano spesso. Sucuri è esplicito sul fatto che questi controlli supportano, anziché sostituire, la gestione degli accessi, le patch, il monitoraggio e la revisione dei fornitori.

Il monitoraggio dovrebbe coprire il sito che i visitatori ricevono, non solo la dashboard del CMS o i file sul server. Il post suggerisce di rivedere le pagine importanti come un visitatore non autenticato e di testare su dispositivi, browser e fonti di traffico diversi, osservando domini esterni sconosciuti, tag HTML personalizzati inspiegati, reindirizzamenti o pop-up inattesi, nuove richieste di verifica o download, cambiamenti nel comportamento del checkout e dei moduli, script che si caricano su pagine non correlate e tag pubblicati al di fuori del processo normale. Alcuni script malevoli si attivano solo su particolari pagine o quando un visitatore soddisfa certe condizioni, quindi il post raccomanda di monitorare il sito così come viene renderizzato e l'attività di rete del browser, poiché una semplice revisione dei file non li rileverebbe.

Se viene trovato uno script non autorizzato, rimuoverlo è solo il primo passo. Sucuri consiglia di conservare l'indirizzo dello script, le pagine interessate, gli screenshot, la cronologia di pubblicazione e l'ora approssimativa in cui il comportamento è iniziato, poi di indagare su come è entrato rivedendo gli account amministratore del CMS, gli utenti del tag manager e la cronologia delle versioni, i plugin, i temi e i campi di codice personalizzato, i file e i database del sito, le credenziali di hosting, deployment e SFTP, e gli account dei fornitori, i token API e i webhook. Le credenziali compromesse dovrebbero essere cambiate, i token esposti revocati, il software vulnerabile aggiornato e l'intero ambiente scansionato alla ricerca di backdoor o altro malware, perché un attaccante che ha ancora accesso può semplicemente rimettere lo script. Se il codice è stato trovato su una pagina di checkout, un modulo di login, un modulo di contatto o qualsiasi altra pagina che gestisce dati sensibili, il post dice di stabilire se le informazioni potrebbero essere state esposte e di segnalare l'incidente ai team competenti per gli aspetti legali, di privacy e di conformità ai pagamenti.

Il post risponde direttamente a due domande comuni. Non sostiene che i siti debbano evitare tutti gli script di terze parti, poiché gli strumenti di analytics, elaborazione dei pagamenti, supporto, accessibilità e marketing offrono un valore reale; l'obiettivo è avere meno script non necessari più una chiara attribuzione di responsabilità, controlli degli accessi e monitoraggio per quelli che restano. E un web application firewall (WAF, un filtro tra i visitatori e il sito) può aiutare a bloccare gli attacchi che portano a una compromissione o a un'iniezione di script, ma non può garantire che un account fornitore approvato o uno script ospitato esternamente resti affidabile. Né eliminare uno script risolve necessariamente il sito, perché potrebbe essere un sintomo di un account amministratore compromesso, di un plugin vulnerabile, di una credenziale rubata, di una voce malevola nel database o di una backdoor persistente.

Per i proprietari di siti WordPress che preferirebbero non portare tutto il carico da soli, il livello di hosting è un punto in cui ridurre il numero di parti in movimento: AEU Hosting, il nostro servizio di hosting WordPress gestito, è costruito in modo che la piattaforma stessa sia gestita e protetta end to end, il che lascia le integrazioni che aggiungi deliberatamente come la parte che possiedi, documenti e rivedi. L'argomentazione conclusiva di Sucuri è che i servizi di terze parti sono una parte normale dei siti web moderni e che il rischio maggiore deriva da script che nessuno traccia, account che nessuno rivede e integrazioni che restano attive senza uno scopo attuale. Tratta ogni tag, pixel, widget ed embed come codice di produzione: assegnagli un responsabile, documenta perché esiste, limita chi può modificarlo, limita dove viene eseguito e monitora l'esperienza offerta ai visitatori.