O Google Chrome começou a liberar para todos os usuários uma defesa que torna o roubo de cookies de sessão praticamente inútil. A funcionalidade, chamada Device Bound Session Credentials (DBSC), vincula a sessão ao hardware do dispositivo onde foi iniciada, impedindo que cookies roubados funcionem em outra máquina. A partir de 25 de maio, a ativação automática começou a alcançar todos os usuários de contas Google, sejam elas pessoais ou do Google Workspace.
O que é DBSC e como funciona a nova proteção do Chrome
DBSC é um mecanismo de segurança que muda a lógica tradicional de proteção de sessões. Em vez de apenas detectar anomalias após o roubo — como era feito até agora —, o DBSC age na raiz do problema: mesmo que um invasor consiga copiar os cookies, eles simplesmente não funcionam em outro dispositivo.
O funcionamento é relativamente simples na teoria, mas robusto na implementação. Quando o usuário faz login em um serviço compatível, o Chrome gera um par de chaves criptográficas (pública e privada) dentro de um componente de segurança do hardware: no Windows, o TPM (Trusted Platform Module); no macOS, a Secure Enclave. A chave privada nunca sai do hardware. O servidor então emite um cookie de sessão de curta duração, que precisa ser renovado periodicamente. A renovação só acontece se o navegador conseguir provar que ainda possui a chave privada correspondente. Como a chave privada está presa ao hardware do dispositivo original, um invasor que tenha roubado apenas o cookie não consegue renová-lo — o cookie expira em instantes e a sessão é perdida.
Por que os cookies de sessão são o alvo preferido dos atacantes
O aumento explosivo de ataques de infostealers (malwares especializados em roubo de informações) explica a urgência da medida. Em 2025, o número de pacotes de dados roubados por infostealers atingiu 51,7 milhões, um crescimento de 72% em relação ao ano anterior. Mais de 24,8 milhões de dispositivos foram infectados, e estima-se que 2,3 bilhões de senhas tenham sido comprometidas.
O que torna os cookies de sessão tão atraentes é que eles eliminam a necessidade de senhas ou autenticação de dois fatores. Um cookie válido prova que o usuário já está logado. Basta copiá-lo do dispositivo infectado e colá-lo no navegador do atacante para assumir a conta. E os cookies geralmente têm longa duração, o que dá ao criminoso uma janela ampla para agir. Mais alarmante ainda: desde o final de 2023, técnicas como a exploração do endpoint MultiLogin do Google OAuth permitiam que atacantes regenerassem cookies mesmo depois de expirados, usando tokens roubados. Malwares como LummaC2 e Rhadamanthys incorporaram rapidamente essa capacidade, tornando o roubo de cookies ainda mais perigoso. O DBSC foi projetado precisamente para encerrar esse tipo de ataque.
Alcance e limitações do DBSC: o que ele protege e o que ainda não cobre
É importante entender que o DBSC não é uma bala de prata. Ele protege exclusivamente cookies de sessão. Um infostealer ainda pode roubar senhas salvas, dados de cartão de crédito, carteiras de criptomoedas, histórico de navegação, configurações de VPN e chaves SSH — tudo isso continua vulnerável. O DBSC atua apenas sobre o mecanismo de sessão, que é o elo mais frágil na cadeia de autenticação.
Além disso, a proteção só funciona quando navegador e serviço web suportam o protocolo. Atualmente, a implementação do lado do Chrome está completa, mas apenas as sessões de contas Google estão protegidas. Outros serviços precisarão implementar os endpoints de registro e renovação do DBSC para que a proteção se estenda a eles. O Google já disponibilizou a especificação e trabalha com a comunidade W3C para transformar o DBSC em um padrão aberto.
Outro ponto importante: o suporte no macOS ainda não foi liberado. A versão para macOS, utilizando a Secure Enclave, está prevista para uma futura versão do Chrome, sem data confirmada. Dispositivos sem TPM também estão em análise — o Google estuda uma alternativa baseada em software, mas ainda em desenvolvimento.
Situação do DBSC em outros navegadores: Edge, Safari e Firefox
O DBSC foi projetado em conjunto por Google e Microsoft como parte do grupo de trabalho de segurança de aplicações web do W3C. O Chromium é a base, mas a adoção entre os navegadores rivais é desigual.
| Navegador | Suporte | Observações |
|---|---|---|
| Chrome (Windows) | ○ | Disponível desde Chrome 146 |
| Chrome (macOS) | △ | Utiliza Secure Enclave, previsto para próxima versão |
| Edge | × | Origin Trial encerrado em outubro de 2025; sem GA anunciado |
| Safari | — | Em fase de avaliação |
| Firefox | — | Em fase de avaliação |
O que muda na prática para o usuário brasileiro
Para quem usa Chrome no Windows com uma conta Google, a proteção já está sendo ativada automaticamente — não é preciso fazer nada. Basta manter o navegador atualizado. A defesa é aplicada às sessões do Google (Gmail, Drive, YouTube, Google Ads, etc.). Para outros sites, a segurança ainda depende de boas práticas individuais: usar um gerenciador de senhas, ativar a autenticação de dois fatores e, principalmente, evitar instalar softwares de origem duvidosa que possam conter infostealers.
O DBSC representa uma mudança estrutural na segurança de sessões web. Por décadas, a premissa era “se roubarem o cookie, o atacante vira você”. Agora, o cookie é inútil fora do dispositivo original. Ainda há um longo caminho para que todos os serviços e navegadores adotem o padrão, mas o primeiro passo foi dado — e ele é significativo.
Referência: Protecting Cookies with Device Bound Session Credentials (Google Security Blog)
