User-Agent

L’header User-Agent dovrebbe identificare il client che effettua una richiesta HTTP — nome del browser, versione, sistema operativo, ecc. È anche l’header più proliferato nella storia di HTTP, che mente sui propri contenuti per ragioni di compatibilità con le versioni precedenti che si accumulano anno dopo anno.

Una tipica stringa User-Agent di Chrome moderna:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36

Chrome dichiara di essere Mozilla, Apple WebKit e Safari, tutti allo stesso tempo. Nessuno di quei token è accurato — esistono perché del codice lato server del 1998 verificava la presenza di “Mozilla” prima di servire HTML moderno, quindi ogni browser successivo ha aggiunto “Mozilla/5.0” per evitare di essere degradato. La stringa è un museo di hack di compatibilità da allora.

Alternative moderne:

• User-Agent Client Hints (famiglia di header Sec-CH-UA) — Chrome ha iniziato a inviare client hint strutturati nel 2020. I server possono attivare tramite Accept-CH. Dati più puliti, impronta predefinita più piccola.
• Rilevamento delle funzionalità invece dello sniffing UA — verifica se l’API di cui hai bisogno esiste piuttosto che indovinare dalla versione del browser.

Le stringhe User-Agent possono essere falsificate banalmente; trattale come un suggerimento, non come un confine di sicurezza. Per i dati analytics, l’UA fornisce una suddivisione approssimativa della quota client; per le decisioni effettive, usa il rilevamento delle funzionalità.

Il progetto di riduzione dello User-Agent di Chrome: Google ha iniziato a ridurre l’entropia della stringa UA nel 2022, bloccando la versione secondaria, eliminando la versione precisa del sistema operativo e unificando le stringhe mobile/desktop. L’obiettivo era ridurre il fingerprinting passivo — una stringa UA può identificare un browser univoco tra centinaia di migliaia di altri puramente dai suoi token di versione build. Entro il 2025 la stringa UA di Chrome è significativamente più breve e meno identificante. Firefox e Safari hanno seguito a ritmi più lenti. I siti che dipendono ancora dall’analisi dell’UA per il rilevamento del browser si stanno rompendo gradualmente — l’API Client Hints moderna (Sec-CH-UA, Sec-CH-UA-Platform, ecc.) è la sostituzione supportata.

User-agent dei bot — convenzione, non applicazione: Googlebot, Bingbot, GPTBot, ClaudeBot e la maggior parte dei crawler commerciali si identificano onestamente nella stringa UA perché devono essere autorizzati oltre il robots.txt e limitati correttamente. Gli scraper che non si identificano spesso falsificano un UA del browser — questo è il motivo per cui la limitazione della velocità e il rilevamento dei bot non possono fare affidamento solo sulle stringhe UA. La gestione moderna dei bot combina UA con il fingerprinting TLS (JA3/JA4), le impostazioni HTTP/2, i segnali mouse/tastiera e i marcatori di browser headless. Un sito che sceglie di consentire solo bot elencati dovrebbe confrontare su più segnali, non solo sull’UA. Riferimento: RFC 9110 §10.1.5 — User-Agent.

Esempio pratico

Vuoi rilevare “l’utente è su iOS Safari” per un controllo di compatibilità Web Push. Sniffing UA ingenuo: /iPhone|iPad|iPod/.test(ua) && /Safari/.test(ua) && !/CriOS|FxiOS/.test(ua). Eccezione: iPadOS 13+ invia l’UA “desktop” per impostazione predefinita, quindi iPad non è nella stringa. Eccezione: Chrome su iOS contiene “CriOS” ma è in realtà WebKit sotto (politica della piattaforma Apple), quindi la negazione è sbagliata. Eccezione: un utente con un’estensione per la privacy potrebbe falsificare il proprio UA in Firefox-su-Linux. Rileva le funzionalità invece: 'serviceWorker' in navigator && 'PushManager' in window && Notification.permission !== 'denied' — tre controlli in una riga, funziona su ogni browser, non si rompe quando Apple rilascia iOS 18 l’anno prossimo. La versione con sniffing UA era già rotta per ~6% degli utenti nel momento in cui è stata distribuita.

Quando e perché è importante

La logica basata sull’UA è la singola maggiore fonte di bug “funziona in Chrome, rotto in Safari” che non sono effettivamente bug del motore del browser. Lato server, tratta l’UA solo come un segnale analytics approssimativo — non bloccare mai funzionalità, contenuti o controlli di sicurezza su di esso. Lato client, preferisci il rilevamento delle funzionalità (Modernizr o controlli manuali per l’API specifica di cui hai bisogno). Per la mitigazione dei bot, combina UA con il fingerprinting TLS (akamai-bot-manager, Cloudflare bot fight mode), segnali comportamentali (entropia dei movimenti del mouse) e sfide proof-of-work (hCaptcha, Turnstile). La situazione dei Client Hints sta migliorando — Sec-CH-UA-Platform è affidabile, Sec-CH-UA-Mobile è affidabile per la distinzione mobile/desktop, ma qualsiasi cosa più specifica richiede ancora il consenso dell’utente tramite Accept-CH. Riferimento: W3C WICG — User-Agent Client Hints.