Guide

Come rilevare browser headless e automazione nella pagina di registrazione

I segnali del browser che tradiscono le registrazioni fatte con Puppeteer, Playwright e Selenium, perché ciascuno può essere falsificato da solo e come combinarli senza bloccare persone reali.

9 min di lettura · Aggiornato il 2026-10-31 · Attrelix

Perché ora i bot usano browser veri

Qualche anno fa la maggior parte dei bot di registrazione erano semplici script HTTP che inviavano direttamente il tuo modulo. Sono facili da fermare: non eseguono JavaScript, quindi nulla di ciò che la tua pagina calcola nel browser arriva al server. Oggi la maggior parte dei bot seri pilota un browser vero tramite Puppeteer, Playwright o Selenium, spesso headless, a volte attraverso un browser anti-detect che maschera la propria impronta. Eseguono il tuo JavaScript, visualizzano la pagina e compilano il modulo come farebbe una persona.

Rilevarli significa cercare i punti in cui un browser automatizzato si differenzia da quello usato da un essere umano. Nessuno dei segnali seguenti è una prova da solo — un operatore determinato può correggerli uno per uno — ma costano poco da raccogliere e si sommano.

Segnale 1: il flag WebDriver

I browser sotto automazione di tipo WebDriver impostano navigator.webdriver a true. Fa parte, deliberatamente, dello standard WebDriver, e le configurazioni predefinite di Selenium, Puppeteer e Playwright lo espongono.

const automated = navigator.webdriver === true;

I plugin “stealth” lo cancellano o lo sovrascrivono, quindi la sua assenza non prova nulla. La sua presenza, invece, è quasi conclusiva: gli utenti reali praticamente non ce l'hanno mai.

Segnale 2: lo user agent headless

Chrome headless si identifica come HeadlessChrome nello user agent, a meno che l'operatore non lo sovrascriva. Controllalo anche sul server, dall'intestazione della richiesta, perché lo user agent che il browser dichiara in JavaScript può differire da quello che invia.

Segnale 3: un client del protocollo DevTools collegato

Puppeteer e Playwright controllano Chrome tramite il protocollo DevTools. Quando un client del protocollo ascolta gli eventi della console, registrare un oggetto spinge il browser a serializzarlo, leggendo persino proprietà che una pagina normale non toccherebbe mai. Un getter che annota se è stato letto è un modo noto per accorgersene:

function devtoolsProtocolAttached() {
  let read = false;
  const e = new Error();
  Object.defineProperty(e, "stack", { get() { read = true; return ""; } });
  console.debug(e);
  return read;
}

Si attiva anche quando uno sviluppatore ha i DevTools aperti, quindi dagli un peso moderato invece di trattarlo come un verdetto.

Segnale 4: rendering software e finestre strane

I browser headless sui server non hanno GPU, quindi WebGL ripiega su un renderer software come SwiftShader o llvmpipe. Puoi leggere il nome del renderer tramite l'estensione WEBGL_debug_renderer_info quando il browser la espone. Alcune configurazioni headless dichiarano anche una finestra di larghezza o altezza zero. Macchine virtuali e desktop remoti condividono questi tratti, quindi da soli sono segnali deboli.

Segnale 5: un'impronta che si contraddice

I browser anti-detect esistono per sembrare tanti browser reali diversi. Ci riescono sovrascrivendo proprietà, e le sovrascritture raramente sono del tutto coerenti. Conviene confrontare:

• Il sistema operativo nello user agent con navigator.platform e gli User-Agent Client Hints.
• La famiglia di browser nello user agent con funzionalità che solo quel motore possiede.
• I font installati con quelli forniti da quel sistema operativo.
• Un canvas disegnato due volte di seguito che produce due immagini diverse — segno di rumore iniettato.
• Notification.permission che dice “denied” mentre la Permissions API dice “prompt”.

Ogni contraddizione da sola è debole, perché estensioni per la privacy e configurazioni insolite ne producono alcune. Due o tre insieme formano uno schema forte.

Segnale 6: il token che non è mai tornato

Una tecnica semplice e robusta: fai chiedere allo script della pagina di registrazione un token di breve durata e monouso, mettilo in un campo nascosto del modulo e verificalo sul server. Un bot che salta il tuo JavaScript arriva senza token valido; uno che riusa un vecchio token arriva con un token già usato. Non serve sapere come funziona il bot per accorgersi che non ha mai eseguito davvero la tua pagina. Mantieni il token monouso, legato al tuo sito, e fallo scadere in pochi minuti.

Segnale 7: il comportamento, non l'impronta

Un'impronta si falsifica; il comportamento molto meno. Una persona legge il modulo, muove il puntatore e digita. Uno script compila i campi e invia poche centinaia di millisecondi dopo il caricamento, senza alcun evento di input attendibile.

La misura affidabile non richiede software aggiuntivo: il tuo agente emette il token visitatore al caricamento della pagina e il server confronta quel momento con l'istante del controllo. Meno di circa un secondo dal caricamento alla registrazione è uno script. Quando l'agente può anche riportare eventi di input attendibili, un invio istantaneo senza eventi di puntatore, tasto o tocco è una seconda conferma indipendente.

Un'avvertenza sul segnale 3: nel Chrome attuale il trucco DevTools scatta solo se il client di automazione si iscrive agli eventi della console, quindi trattalo come un bonus e non come rivelatore principale.

Combina, non bloccare su un solo segnale

Tratta ogni segnale come punti in un punteggio e decidi sul totale. Una ponderazione ragionevole per iniziare, dal più forte al più debole:

Unisci i segnali del browser a quelli del server — registrazioni da intervalli IP cloud, raffiche da una sottorete, account collegati allo stesso dispositivo — e pochissimi bot sembreranno puliti su tutti contemporaneamente.

Cosa non fare

• Non bloccare solo per l'assenza di plugin o lingue. I browser rafforzati per la privacy li eliminano.
• Non distribuire la logica di rilevamento come controlli dai nomi ovvi che un operatore può cercare e aggirare in un colpo; raccogli dati grezzi nel browser e decidi sul server.
• Non fidarti ciecamente di ciò che dichiara il browser. Il client è sotto il controllo del bot. La verifica avviene sul tuo server, con il tuo segreto.

Come lo fa Attrelix

L'agente Attrelix raccoglie questi dati del browser e un token visitatore monouso nella tua pagina di registrazione; il server li combina con i segnali di rete, casella e account collegati in un unico punteggio. Tutti i pesi sono pubblici nella documentazione, e nessun segnale debole da solo può mandare una registrazione in verifica.

In sintesi

• I bot moderni usano browser veri; cerca dove l'automazione si distingue da una persona.
• WebDriver, user agent headless e token mancanti sono forti; il resto è debole ma si somma.
• Decidi sul server, con un punteggio, mai in base a un singolo flag del browser.