TL;DR: il fingerprinting non passa necessariamente da cookie o pixel visibili. Uno script può combinare Web Audio, canvas, WebGL, caratteristiche del dispositivo e segnali di interazione per distinguere un browser. Per un sito WordPress la difesa pratica è un inventario delle terze parti, un audit di rete nei diversi stati del consenso, la risalita all’initiator e una rimozione controllata su staging. Il cookie banner da solo non basta.

Un ricercatore ha scoperto un comportamento anomalo su AliExpress perché le sue cuffie Bluetooth multipoint smettevano di riprodurre l’audio del telefono quando apriva il sito dal computer. Nessun video, nessun player e nessun suono udibile. La pagina stava però creando due contesti Web Audio, collegati all’uscita di sistema con il guadagno impostato a zero.

Il caso è interessante per chi gestisce siti aziendali perché mostra un limite dei controlli abituali. Guardare soltanto cookie, tag noti e banner di consenso lascia fuori ciò che il browser può calcolare o trasmettere tramite JavaScript. Il punto non è accusare ogni libreria che usa Web Audio: la stessa API serve per editor, strumenti musicali, videoconferenze e accessibilità. Il punto è sapere quale codice gira, perché gira e dove invia i risultati.

Questa guida trasforma l’episodio in una procedura per auditare un sito WordPress senza bloccare alla cieca analytics, antifrode o funzioni necessarie.

Il caso AliExpress: il problema non era il suono

Il 20 agosto 2026 Matthew Callaghan ha documentato la sua analisi. Dopo alcuni secondi dalla visita alla homepage, due script offuscati creavano un grafo composto da oscillatore, analizzatore, processore e nodo di guadagno a zero. Il browser elaborava quindi una forma d’onda senza renderla udibile. Sul suo sistema, il collegamento all’uscita audio bastava a mantenere attivo il percorso Bluetooth del computer.

Callaghan ha osservato anche letture di canvas, WebGL, dimensioni dello schermo, memoria e concorrenza hardware, formati supportati, WebRTC, timing e interazioni. Ha inoltre trovato codice per serializzare i risultati e trasmetterli verso servizi di telemetria. Dal client non poteva però provare durata della conservazione, collegamento a un’identità o finalità server-side. Questi limiti contano: l’audit deve separare ciò che il browser dimostra dalle ipotesi sul trattamento successivo.

Ars Technica ha ripreso il caso il 24 agosto 2026. Il dettaglio più utile non è l’effetto sulle cuffie, ma la combinazione dei segnali. Un singolo valore audio può essere poco discriminante; insieme ad altre caratteristiche del browser può contribuire a un profilo più stabile.

La specifica ufficiale Web Audio del W3C tratta esplicitamente il fingerprinting. OscillatorNode e DynamicsCompressorNode possono esporre differenze dovute a implementazione DSP, arrotondamenti e architettura CPU. La specifica chiede ai browser di mitigare questa superficie.

Mozilla lo ha fatto in Firefox 118 usando la stessa libreria matematica su tutti i sistemi. Le note di rilascio collegano la modifica alla protezione dal fingerprinting. Tom Ritter, sviluppatore Firefox, ha analizzato il codice emerso nel caso Alibaba e sostiene che questa specifica tecnica Web Audio oggi distingua soprattutto pochi gruppi di architetture. Non significa che il fingerprinting sia sparito: significa che bisogna valutare l’insieme, non drammatizzare un singolo segnale.

Perché il cookie scan non basta

Un cookie scanner cerca storage, richieste e firme conosciute. È utile, ma vede solo una parte dell’esecuzione. Il fingerprinting può produrre un identificatore sul momento, senza scriverlo subito in un cookie. Un endpoint può ricevere caratteristiche tecniche tramite fetch() o sendBeacon(). Un tag caricato da un dominio approvato può a sua volta importare codice diverso.

Anche la distinzione tra “analytics” e “sicurezza” è meno pulita di quanto sembri. Un sistema antifrode ha motivi legittimi per distinguere un browser umano da un bot. Lo stesso insieme di segnali può però essere riutilizzato per riconoscere il dispositivo tra più sessioni. Dal pannello WordPress non lo capisci. Devi osservare il comportamento effettivo e confrontarlo con contratto, documentazione e configurazione.

La mia take è questa: la reputazione del fornitore non è un controllo tecnico. Un plugin famoso, un tag inserito da un’agenzia o una libreria caricata da un CDN rimangono codice eseguibile nel browser del cliente. Il proprietario del sito deve sapere chi ne risponde e avere un modo rapido per disattivarlo.

Mappa cosa carica davvero WordPress

L’audit va fatto su staging o su una copia controllata, con cache e ottimizzazioni equivalenti al live. Prepara almeno quattro percorsi: homepage, pagina contenuto, form o area lead e, se esiste, checkout o area riservata. Ripetili senza consenso, con sole preferenze necessarie e con consenso completo. Usa una finestra anonima per evitare estensioni e sessioni che alterano il risultato.

Nel pannello Network di Chrome DevTools attiva “Preserve log”, disabilita la cache e ricarica la pagina. La documentazione ufficiale di Chrome conferma che il pannello registra le richieste mentre è aperto, consente di filtrare quelle di terze parti e mostra la colonna Initiator. Quest’ultima è decisiva: risale dal dominio esterno allo script, all’iframe o al tag che ha avviato la richiesta.

Per un primo inventario puoi eseguire nella Console questo frammento diagnostico:

const hostPagina = location.hostname;
const risorse = performance.getEntriesByType('resource')
  .map(({ name, initiatorType }) => ({
    host: new URL(name).hostname,
    tipo: initiatorType,
    url: name
  }))
  .filter(({ host }) => host !== hostPagina);

console.table(risorse);

Non è un rilevatore di fingerprinting e non sostituisce il log Network. Serve a ottenere una lista veloce degli host diversi dal dominio corrente. Esporta poi un HAR sanificato da DevTools: il formato conserva richieste e initiator, mentre l’opzione sanificata esclude header sensibili come Cookie, Set-Cookie e Authorization. Non condividere un HAR completo con fornitori se contiene sessioni reali.

Per ogni script risali al proprietario dentro WordPress:

  • tema o child theme tramite wp_enqueue_script();
  • plugin che inietta asset o iframe;
  • Google Tag Manager o altro tag manager;
  • consent management platform;
  • widget di chat, mappe, video, recensioni, pagamento o antifrode;
  • codice aggiunto nel builder, negli snippet o nell’header globale.

Nome del dominio e nome del plugin spesso non coincidono. Usa l’initiator, la stack trace e la ricerca globale nei file caricati. Se la sorgente è offuscata, registra comunque URL, versione, hash, pagina e momento del caricamento.

Cerca segnali concreti, non parole sospette

Nel pannello Sources cerca chiamate a AudioContext, OfflineAudioContext, OscillatorNode, AnalyserNode, getFloatFrequencyData(), toDataURL(), WEBGL_debug_renderer_info e sendBeacon(). Chrome include anche un pannello WebAudio per osservare stato e metriche degli AudioContext attivi.

Una corrispondenza non è una prova di abuso. Un configuratore prodotto può usare canvas; una call usa WebRTC; un editor audio deve creare AudioContext. Il segnale diventa rilevante quando API, pagina, momento e destinazione non sono coerenti con la funzione dichiarata. Un oscillatore su una pagina senza audio, avviato prima del consenso e seguito da una richiesta di telemetria, merita più attenzione di un AudioContext creato dopo il clic su “Riproduci”.

Documenta ogni osservazione con una scheda minima:

  1. owner interno e fornitore;
  2. funzione dichiarata e pagine in cui serve;
  3. script iniziale, catena degli initiator e domini contattati;
  4. API del browser usate e dati tecnici letti;
  5. stato del consenso in cui parte;
  6. azione utente che lo attiva, se presente;
  7. effetto della disattivazione su funzioni e conversioni;
  8. data dell’ultima revisione e procedura di rollback.

Questo registro completa il lavoro sui controlli di accesso, costi e dati nei workflow AI: in entrambi i casi una dipendenza esterna va trattata come parte dello stack, non come una scatola chiusa.

Riduci il rischio senza rompere il sito

Il primo intervento è togliere ciò che non ha più un owner. I siti WordPress accumulano tag di campagne concluse, widget sostituiti e plugin che continuano a caricare JavaScript dopo la disattivazione della funzione visibile. Se nessuno sa spiegare perché una dipendenza è necessaria, spostala su staging, disabilitala e misura.

Il secondo è verificare il consenso sul traffico, non solo sull’interfaccia della CMP. Registra la pagina prima di qualsiasi scelta e controlla che i tag non necessari restino fermi. Ripeti dopo rifiuto e accettazione. Un pulsante che cambia colore non prova che le richieste siano state bloccate.

Il terzo è introdurre una Content Security Policy in modalità Report-Only. L’header Content-Security-Policy-Report-Only permette di raccogliere violazioni senza applicare subito il blocco; MDN raccomanda di configurare anche una destinazione tramite report-to. Parti da staging, raccogli i report, costruisci l’allowlist e passa all’enforcement solo dopo i test.

La CSP ha un limite preciso. Può controllare origini di script e destinazioni di rete, ma non impedisce a uno script già autorizzato e servito dal dominio corretto di usare Web Audio o canvas. Per quello servono revisione del fornitore, isolamento e possibilità di rimozione. Non trasformare una lunga allowlist in un bollino di sicurezza.

Il quarto è limitare la superficie per pagina. Un widget necessario al checkout non deve girare anche su articoli e homepage. Carica mappe, video e chat al clic quando possibile. Riduci così richieste, raccolta involontaria e lavoro JavaScript, con un beneficio anche sulle performance.

Infine testa il rollback. Disattiva una dipendenza alla volta su staging, svuota le cache applicative e CDN, poi ripeti i flussi critici. Conserva screenshot, HAR sanificato e risultato. È lo stesso principio usato per la risposta agli incidenti nella supply chain AI: inventario e procedura di sostituzione contano più della promessa del fornitore.

Caso studio: audit WordPress in 90 minuti

Per una PMI partirei da un audit breve e ripetibile, non da un progetto di compliance infinito.

Nei primi 15 minuti definisci quattro pagine e tre stati del consenso. Annota tema, builder, plugin che inseriscono codice frontend, tag manager e widget. Non aprire ancora il codice: costruisci la mappa attesa.

Nei successivi 25 minuti registra i percorsi in DevTools. Filtra le richieste di terze parti, controlla quelle avviate prima del consenso ed esporta un HAR sanificato per ogni stato. Segna i domini non presenti nella mappa attesa.

Dedica 20 minuti agli initiator. Per ogni dominio sconosciuto risali allo script padre e poi al plugin, al container o allo snippet WordPress. Cerca le API ad alta entropia solo nelle catene dubbie. Non perdere tempo a leggere tutto il JavaScript minificato del sito.

Usa altri 20 minuti per l’isolamento su staging. Disattiva il componente sospetto, pulisci la cache e ripeti la stessa azione. Se la richiesta sparisce e il flusso resta integro, hai una rimozione candidata. Se si rompe una funzione, hai almeno identificato dipendenza e costo.

Negli ultimi 10 minuti assegna tre esiti: mantenere con documentazione, limitare a pagine o stati specifici, rimuovere. Ogni “mantenere” deve avere owner, finalità, domini, scadenza di revisione e rollback. Le voci senza owner non restano in produzione per inerzia.

Cosa controllare ogni mese

  • nuovi domini terzi rispetto all’HAR di riferimento;
  • tag che partono prima del consenso o dopo un rifiuto;
  • script caricati su pagine dove la funzione non serve;
  • cambi di versione senza changelog o owner interno;
  • nuove chiamate a API di fingerprinting nelle dipendenze più esposte;
  • possibilità reale di disattivare il fornitore senza fermare il sito.

Non serve dichiarare “zero fingerprinting” dopo una singola scansione. Serve poter spiegare il comportamento osservato, accorgersi delle differenze e intervenire. Su WordPress questo è fattibile: inventario, Network, initiator, staging e CSP Report-Only coprono già la parte più trascurata.

Il caso AliExpress è un promemoria utile proprio perché il segnale era laterale: delle cuffie che non cambiavano sorgente. Un controllo maturo non aspetta l’effetto visibile. Misura il codice di terze parti come misura uptime, performance e sicurezza.

Fonti