Perché gli script di terze parti non gestiti mettono a rischio il tuo sito web

Gli script di terze parti sono una componente comune dei siti web moderni e alimentano funzionalità di analisi, pubblicità, chat dal vivo, video, social media e pagamenti. Le linee guida sulla sicurezza di Sucuri chiariscono che, sebbene queste integrazioni non siano automaticamente pericolose, ogni tag esterno, pixel, widget o incorporamento aggiunge un ulteriore punto di vulnerabilità. Tali strumenti possono leggere il contenuto della pagina, raccogliere dati sui visitatori, alterare ciò che gli utenti vedono e comunicare con servizi esterni. Se un fornitore, un account o una configurazione viene compromesso, l'impatto può estendersi a ogni pagina che carica lo script. I proprietari dei siti non dovrebbero cercare di rimuovere integrazioni utili, ma dovrebbero capire quali script vengono eseguiti, perché sono necessari, chi li controlla e come individuare modifiche inaspettate.

Uno script di terze parti è codice JavaScript o altro codice incorporato in un sito web ma caricato da un dominio o servizio esterno al controllo diretto del proprietario del sito. Esempi comuni includono tag di analisi e pixel pubblicitari, contenitori di tag management, widget di chat dal vivo e assistenza clienti, mappe di calore e strumenti di registrazione delle sessioni, piattaforme di test A/B e personalizzazione, strumenti di gestione del consenso, moduli e video incorporati, strumenti di pianificazione, integrazioni per pagamenti e prevenzione delle frodi, integrazioni social media e librerie JavaScript ospitate su reti di distribuzione di contenuti esterne. Quando i team di sicurezza esaminano un sito, dovrebbero considerare anche iframe, plugin, blocchi HTML personalizzati e integrazioni CMS che caricano risorse esterne, perché ciascuno di questi aggiunge un altro servizio che potrebbe influenzare il sito o i suoi visitatori.

Questi script diventano un rischio per la sicurezza quando hanno un accesso eccessivo, sono gestiti male, provengono da una fonte compromessa o rimangono attivi dopo che il loro scopo commerciale è terminato. OWASP osserva che i tag di marketing e analisi possono leggere i dati da una pagina e inviarli a servizi esterni. I tag manager possono decidere quali script caricare, quali informazioni ricevono tali script e dove vengono inviati i dati. Sucuri evidenzia quattro rischi che meritano particolare attenzione.

Il primo rischio è che il codice esterno possa cambiare senza un aggiornamento del sito. Un file ospitato localmente normalmente cambia solo quando qualcuno aggiorna il sito, ma uno script ospitato esternamente può essere modificato alla sua origine mentre il suo URL e la sua posizione rimangono invariati. Ciò consente ai fornitori di aggiornare i propri servizi senza richiedere ai clienti di ridistribuire il codice, ma significa anche che se un fornitore, una rete di distribuzione di contenuti o un account viene compromesso, l'attaccante può iniziare a distribuire codice modificato a ogni sito web che carica la risorsa.

Il secondo rischio è che i tag manager concentrano l'accesso alla pubblicazione. Questi strumenti consentono ai team di marketing e analisi di aggiungere script senza modificare direttamente il sito, ma questa comodità crea un punto di controllo di alto valore. Un singolo account di tag management compromesso può consentire a un attaccante di pubblicare codice su un intero sito web. Il rischio è amplificato da credenziali condivise, permessi eccessivi, mancanza di autenticazione multifattoriale e accesso di pubblicazione non revisionato.

Il terzo rischio è che gli script dannosi possano imitare strumenti fidati. Gli attaccanti sanno che gli amministratori si aspettano di vedere tag di analisi e pixel di monitoraggio familiari. I ricercatori di Sucuri hanno documentato uno skimmer di carte di credito mascherato da tracker di Facebook Pixel. La versione dannosa utilizzava nomi e formattazione familiari ma sostituiva il dominio legittimo con una fonte controllata dall'attaccante, quindi prendeva di mira le pagine di checkout e catturava le informazioni di pagamento. Uno script può sembrare familiare senza essere legittimo, quindi il dominio, la fonte, il comportamento e il metodo di installazione contano tutti.

Il quarto rischio è che le pagine di pagamento affrontino conseguenze maggiori. Nelle pagine di checkout, gli script lato browser sono particolarmente pericolosi perché possono interagire con i moduli di pagamento o con i dati inseriti dal cliente. I requisiti PCI DSS 6.4.3 e 11.6.1 si concentrano sull'autorizzazione degli script delle pagine di pagamento, sulla verifica 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. I siti web al di fuori dell'ambito PCI DSS possono applicare lo stesso principio: le pagine sensibili dovrebbero caricare solo risorse note, necessarie e monitorate.

La responsabilità per la sicurezza degli script di terze parti è condivisa tra team di sito web, sicurezza, sviluppo, marketing, e-commerce e contenuti. I team tecnici possono valutare come funziona uno script e quali controlli sono disponibili, mentre i proprietari dell'attività di solito sanno perché lo strumento è stato aggiunto, quale campagna o funzione supporta, chi gestisce il rapporto con il fornitore e se lo strumento è ancora necessario. Ogni integrazione dovrebbe avere un proprietario interno nominato. Senza uno, strumenti di campagne obsolete e account abbandonati possono rimanere collegati alla produzione molto tempo dopo che qualcuno li ha effettivamente revisionati.

Per ridurre il rischio, Sucuri raccomanda una combinazione di chiara proprietà, accesso limitato, pulizia di routine, controlli tecnici e monitoraggio rivolto ai visitatori. Il primo passo è mantenere un inventario di script e integrazioni. Documentare ogni servizio esterno approvato che può influenzare il sito web, inclusi nome dello strumento e del fornitore, scopo commerciale, proprietario interno, pagine in cui viene caricato, dati che raccoglie o elabora, come è stato installato, utenti con accesso amministrativo o di pubblicazione, data di aggiunta e prossima data di revisione. Confrontare periodicamente questo inventario con il sito web live; qualsiasi script trovato sul sito ma mancante dall'inventario dovrebbe essere indagato.

Successivamente, limitare l'accesso e richiedere l'autenticazione multifattoriale. Utilizzare account individuali invece di credenziali condivise, seguire il principio del privilegio minimo dando agli utenti solo i permessi richiesti dal loro ruolo e mantenere i diritti di pubblicazione in produzione per un gruppo più ristretto. Abilitare l'autenticazione multifattoriale per tag manager, piattaforme di analisi, account pubblicitari, dashboard CMS, account di hosting e altri servizi collegati. Rivedere l'accesso ogni volta che i dipendenti cambiano ruolo o quando i rapporti con agenzie e fornitori terminano.

Trattare le modifiche ai tag come rilasci del sito. Uno script introdotto tramite una dashboard può avere lo stesso effetto diretto sui visitatori del codice distribuito tramite un flusso di lavoro di sviluppo. Prima di pubblicare un tag, documentare il suo scopo, identificare le pagine e i dati interessati, testarlo fuori dalla produzione se possibile, farlo revisionare da un'altra persona autorizzata, annotare l'editore e la data di pubblicazione e mantenere un percorso di rollback. Il processo non deve essere lento, ma dovrebbe rendere le modifiche in produzione visibili e responsabili.

Caricare ogni script solo dove è necessario. Un pixel di conversione per una singola campagna potrebbe non dover essere caricato sull'intero sito web. Un'integrazione di checkout non dovrebbe apparire su post di blog non correlati e uno strumento di registrazione delle sessioni potrebbe dover escludere pagine di login, account, moduli o pagamenti. Limitare dove uno script può essere eseguito riduce la quantità di dati esposti inutilmente e limita il possibile impatto di un'integrazione compromessa.

Rimuovere strumenti e accessi scaduti. Le integrazioni temporanee tendono a sopravvivere alle campagne che le hanno introdotte. Quando si ritira uno strumento, rimuovere i suoi script e tag, revocare le sue chiavi API e token, eliminare webhook inutilizzati, rimuovere account fornitori e verificare che la risorsa non appaia più quando si carica il sito web pubblico. Una data di scadenza o di revisione può impedire che la tecnologia temporanea diventi infrastruttura permanente.

Utilizzare controlli lato browser quando appropriato. Una Content Security Policy (CSP) può limitare le fonti da cui un browser è autorizzato a caricare script e altre risorse. Aiuta a ridurre gli effetti dell'iniezione di script non autorizzati ma richiede test approfonditi per evitare di bloccare funzioni legittime del sito. Subresource Integrity (SRI) consente a un browser di verificare che una risorsa esterna compatibile corrisponda a un hash crittografico previsto prima di caricarla. SRI funziona meglio per file fissi e potrebbe non essere adatto a script di fornitori che cambiano frequentemente. Questi controlli dovrebbero supportare, non sostituire, la gestione degli accessi, le patch, il monitoraggio e la revisione dei fornitori.

Monitorare il sito web che i visitatori ricevono effettivamente. Non fare affidamento solo sulla dashboard CMS o sui file del server. Rivedere le pagine importanti come visitatore disconnesso e testare diversi dispositivi, browser e fonti di traffico. Osservare domini esterni sconosciuti, tag HTML personalizzati inspiegabili, reindirizzamenti o pop-up inaspettati, nuovi prompt 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 quando vengono soddisfatte condizioni specifiche del visitatore, quindi il monitoraggio del sito web renderizzato e dell'attività di rete può rilevare comportamenti che una semplice revisione dei file non noterebbe.

Se trovi uno script non autorizzato, rimuovere il codice visibile è solo il primo passo. Conserva i dettagli inclusi URL dello script, pagine interessate, screenshot, cronologia di pubblicazione e l'ora approssimativa in cui il comportamento è iniziato. Quindi indaga su come è stato introdotto esaminando gli account amministratore CMS, gli utenti e la cronologia delle versioni del tag manager, plugin, temi, campi di codice personalizzati, file del sito web e database, credenziali di hosting e distribuzione e account fornitori, token API e webhook. Cambia le credenziali compromesse, revoca i token esposti, applica patch al software vulnerabile e scansiona l'intero ambiente per backdoor o malware aggiuntivo. Un attaccante che ha ancora accesso potrebbe semplicemente ripristinare lo script. Se il codice appare su una pagina di checkout, login, contatto o altra pagina sensibile, determina se alcune informazioni potrebbero essere state esposte e segnala l'incidente ai team legali, privacy e conformità dei pagamenti pertinenti.

Le linee guida di Sucuri rispondono a domande comuni. I siti web non devono evitare tutti gli script di terze parti, perché analisi, elaborazione dei pagamenti, supporto, accessibilità e strumenti di marketing possono offrire valore reale. L'approccio migliore è ridurre gli script non necessari e richiedere chiara proprietà, controlli di accesso e monitoraggio per quelli mantenuti. Un web application firewall può aiutare a bloccare attacchi che portano a compromissione o iniezione di script, ma non può garantire che un account fornitore approvato o uno script ospitato esternamente rimanga affidabile. 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, una credenziale rubata, una voce di database dannosa o una backdoor persistente. Il percorso di accesso originale deve essere identificato e chiuso.

I servizi di terze parti sono una parte normale dei siti web moderni, ma il rischio maggiore deriva da script che nessuno traccia, account che nessuno rivede e integrazioni senza uno scopo attuale. Tratta ogni tag, pixel, widget e incorporamento come codice di produzione: dagli un proprietario, documenta perché esiste, limita chi può modificarlo, limita dove viene eseguito e monitora l'esperienza fornita ai visitatori. Per i proprietari di siti che desiderano una base operativa sicura mentre applicano questi controlli, l'hosting WordPress gestito come AEU Hosting fornisce un ambiente sicuro end-to-end che può supportare inventari di script e limiti di accesso.