Skip to content

Glossary

User-Agent

O header HTTP que mente sobre si mesmo

By Published Updated

O header User-Agent deve identificar o cliente que faz uma requisição HTTP — nome do navegador, versão, SO etc. É também o header mais sobrecarregado da história do HTTP, mentindo sobre seu próprio conteúdo por razões de compatibilidade retroativa que se acumulam ano após ano.

Uma string User-Agent típica do Chrome moderno:

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

O Chrome afirma ser Mozilla, Apple WebKit e Safari, tudo ao mesmo tempo. Nenhum desses tokens é preciso — eles existem porque algum código de servidor de 1998 verificava “Mozilla” antes de servir HTML moderno, então cada navegador subsequente adicionou “Mozilla/5.0” para evitar ser rebaixado. A string tem sido um museu de hacks de compatibilidade desde então.

Alternativas modernas:

  • User-Agent Client Hints (família de headers Sec-CH-UA) — o Chrome começou a enviar client hints estruturados em 2020. Os servidores podem optar via Accept-CH. Dados mais limpos, menor footprint padrão.
  • Detecção de recursos em vez de sniffing de UA — verifique se a API que você precisa existe em vez de adivinhar pela versão do navegador.

As strings User-Agent podem ser falsificadas trivialmente; trate-as como uma dica, não como um limite de segurança. Para análises, o UA fornece uma distribuição aproximada de clientes; para decisões reais, detecte recursos.

O projeto de redução de User-Agent do Chrome: o Google começou a reduzir a entropia da string UA em 2022, congelando a versão secundária, eliminando a versão exata do SO e unificando as strings de celular/desktop. O objetivo era reduzir a impressão digital passiva — uma string UA pode identificar um navegador exclusivo entre centenas de milhares de outros puramente a partir de seus tokens de versão de build. Até 2025 a string UA do Chrome é significativamente mais curta e menos identificadora. Firefox e Safari seguiram em ritmos mais lentos. Sites que ainda dependem da análise do UA para detecção de navegador estão quebrando lentamente — a API Client Hints moderna (Sec-CH-UA, Sec-CH-UA-Platform etc.) é o substituto suportado.

User-agents de bots — convenção, não imposição: Googlebot, Bingbot, GPTBot, ClaudeBot e a maioria dos rastreadores comerciais se identificam honestamente na string UA porque precisam ser permitidos pelo robots.txt e com limite de taxa justo. Scrapers que não se identificam frequentemente falsificam um UA de navegador — razão pela qual limitação de taxa e detecção de bots não podem depender apenas de strings UA. O gerenciamento moderno de bots combina UA com impressão digital TLS (JA3/JA4), configurações HTTP/2, sinais de mouse/teclado e marcadores de navegador headless. Um site que deseja permitir apenas bots listados deve corresponder em múltiplos sinais, não apenas no UA. Referência: RFC 9110 §10.1.5 — User-Agent.

Exemplo prático

Você quer detectar “o usuário está no iOS Safari” para uma verificação de compatibilidade com Web Push. Sniff de UA ingênuo: /iPhone|iPad|iPod/.test(ua) && /Safari/.test(ua) && !/CriOS|FxiOS/.test(ua). Exceto: o iPadOS 13+ envia o UA “desktop” por padrão, então iPad não está na string. Exceto: o Chrome no iOS contém “CriOS” mas é na verdade WebKit por baixo (política da plataforma Apple), então a negação está errada. Exceto: um usuário com extensão de privacidade pode falsificar seu UA para Firefox no Linux. Detecte recursos em vez disso: 'serviceWorker' in navigator && 'PushManager' in window && Notification.permission !== 'denied' — três verificações de linha, funciona em todos os navegadores, não quebra quando a Apple lança o iOS 18 no próximo ano. A versão de sniff de UA já estava quebrada para ~6% dos usuários quando foi lançada.

Quando e por que isso importa

A lógica baseada em UA é a maior fonte de bugs “funciona no Chrome, quebrado no Safari” que não são bugs reais de motor de navegador. No servidor, trate o UA apenas como um sinal de análise grosseiro — nunca bloqueie recursos, conteúdo ou verificações de segurança nele. No cliente, prefira detecção de recursos (Modernizr ou verificações manuais para a API específica que você precisa). Para mitigação de bots, combine UA com impressão digital TLS (akamai-bot-manager, Cloudflare bot fight mode), sinais comportamentais (entropia de movimento do mouse) e desafios de prova de trabalho (hCaptcha, Turnstile). A história dos Client Hints está melhorando — Sec-CH-UA-Platform é confiável, Sec-CH-UA-Mobile é confiável para distinção celular/desktop, mas qualquer coisa mais específica ainda requer opt-in do usuário via Accept-CH. Referência: W3C WICG — User-Agent Client Hints.

Frequently asked questions

O que é o header HTTP User-Agent?
O header User-Agent é enviado por navegadores e clientes HTTP com cada requisição para identificar o software que faz a requisição — geralmente incluindo nome do navegador, versão, motor e SO. Os servidores o usam para personalizar respostas ou análises.
Por que a string User-Agent é notoriamente não confiável?
Por compatibilidade retroativa, os navegadores historicamente afirmavam ser outros navegadores (o Chrome diz ser Mozilla/5.0; Safari; Chrome). Isso se acumulou ao longo de décadas, pois sites serviam conteúdo apenas a strings reconhecidas. As strings User-Agent modernas contêm tokens de vários navegadores que não são, tornando a análise para detecção de recursos não confiável.
Qual é a diferença entre User-Agent e Client Hints?
User-Agent é uma única string de header enviada automaticamente com cada requisição, contendo tudo de uma vez. Client Hints (Sec-CH-UA-*) é uma API mais nova que permite que os servidores solicitem apenas os atributos específicos de dispositivo que precisam, reduzindo a superfície de impressão digital e dando aos navegadores mais controle de privacidade.

Related

Published May 15, 2026 · Last reviewed May 31, 2026