Resposta rápida: implemente o DBSC onde puder. É uma boa proteção gratuita contra o reuso de cookies roubados no Chrome. Mas o DBSC faz um único trabalho específico: é só para Chrome, pós-login, antirroubo mais do que antifraude, e projetado com critérios de privacidade para não lhe dar nenhuma identidade de dispositivo. O fingerprint de dispositivo responde a uma pergunta diferente, e o DBSC foi deliberadamente construído para não respondê-la. Tratar o DBSC como substituto do fingerprint é um erro de categoria.
O Device Bound Session Credentials (DBSC) do Google chegou à disponibilidade geral no Chrome 146 no Windows em 2026-04-10. No momento em que foi lançado, uma pergunta justa caiu sobre cada equipe de fraude e segurança: se o Chrome agora vincula as sessões ao dispositivo de graça, por que ainda pagar por fingerprint?
A resposta honesta começa com uma concessão. Para o seu único trabalho, o DBSC é realmente sólido, mais sólido do que um fingerprint. O resto deste artigo trata de tudo o que esse trabalho não inclui.
O que é o DBSC, agora que está em disponibilidade geral
O DBSC vincula uma sessão a uma chave privada guardada no hardware seguro do dispositivo, um TPM no Windows ou o Secure Enclave no macOS. A chave não pode ser exportada. A cada cinco minutos, aproximadamente, o navegador prova que ainda tem essa chave, e só então o servidor renova um cookie de curta duração. Roube o cookie e mova-o para outra máquina, e ele morre, porque o ladrão não consegue reproduzir a prova vinculada ao hardware.
Isso fecha exatamente a janela de reuso que o malware infostealer e os kits de phishing adversário-no-meio exploram em larga escala. Para um olhar mais profundo sobre por que a sessão do navegador virou um plano de controle, veja a sessão do navegador agora é um plano de controle de segurança.
Onde o DBSC é realmente melhor
Para tornar um cookie roubado inútil em outro dispositivo, a vinculação criptográfica por hardware supera um fingerprint, e vale a pena dizer isso com clareza.
Um fingerprint é sinal observável. Um atacante determinado em um dispositivo semelhante pode imitar o suficiente para parecer a vítima. Em nossos próprios testes, as defesas contra bots baseadas em fingerprint invalidam com força o reuso automatizado, mas ficam frágeis diante de um atacante humano que reusa um cookie roubado a partir de um dispositivo semelhante. Uma chave privada vinculada ao TPM não tem essa borda frágil: ela não pode ser extraída, então o reuso simplesmente falha.
Por isso a cside não afirma ser melhor para impedir o roubo de cookies. Para essa fatia, não é. Conceda o ponto e suba um nível, porque é no nível de cima que vive a maior parte da fraude.
DBSC versus fingerprint de dispositivo num relance
| Ataque ou necessidade | DBSC | Fingerprint de dispositivo (cside) |
|---|---|---|
| Cookie roubado reusado fora do dispositivo | Forte: a chave de hardware não pode ser reproduzida | Parcial: detecta a troca de dispositivo, pode ser imitado |
| Roubo de credenciais e phishing | Nenhuma: também vincula o dispositivo do atacante | Sinaliza credenciais válidas em um dispositivo novo |
| Credential stuffing | Nenhuma: atua depois do login | Detecta padrões automatizados e de dispositivo repetido |
| Fraude de contas novas e sintéticas | Nenhuma: ainda não existe sessão | Funciona no cadastro |
| Cadastros de bots, scraping, carding | Nenhuma | Caso de uso central, antes da autenticação |
| Entre contas e multiconta | Nenhuma: as chaves não são correlacionáveis por design | Vincula dispositivos entre contas |
| Reputação de dispositivo e score de risco | Nenhuma | Sim |
| Cobertura de navegadores | Chrome no Windows hoje | Todos os navegadores, cada visitante |
| Implementação | Rearquitetura da sessão no servidor | Integração direta no caminho do script de primeira parte |
| Visibilidade para os atacantes | Protocolo público e detectável | Estruturalmente invisível no caminho de primeira parte |
Por que você ainda precisa do fingerprint de dispositivo
O DBSC vincula quem fizer login, inclusive o atacante
Este é o ponto que mais importa. O DBSC defende contra o roubo de cookies, em que o malware toma uma sessão que já pertence à vítima. Ele não faz nada contra roubo de credenciais, phishing ou credential stuffing. Se um atacante tem a senha, o DBSC alegremente emite a ele uma sessão limpa, vinculada ao dispositivo dele. A vinculação é real. Só que está vinculada à pessoa errada.
O fingerprint é o que detecta o caminho real do roubo de contas: credenciais válidas chegando de um dispositivo novo. O DBSC abençoa exatamente o caso que o fingerprint foi feito para sinalizar. Para toda a cadeia de ataque, veja comparando soluções para prevenção de roubo de contas.
O DBSC só funciona depois do login
A fraude acontece antes de existir uma sessão para vincular. Fraude de contas novas, identidades sintéticas, cadastros de bots, tentativas de credential stuffing, scraping, carding e abuso de bônus são todos eventos antes da autenticação ou entre contas. Ainda não há uma credencial de sessão para vincular criptograficamente, então o DBSC não tem nada sobre o que agir.
O fingerprint funciona no cadastro, no login, no checkout e na redefinição de senha, os momentos em que o abuso antes da autenticação é decidido.
O DBSC foi projetado para não ser uma camada de identidade de dispositivo
Isso é uma característica, não uma falha, e convém entender bem. As chaves do DBSC são por sessão, por origem e deliberadamente não correlacionáveis, justamente para que o mecanismo não possa virar um vetor de rastreamento ou vinculação. Isso é bom para os usuários.
Também é um muro duro para as equipes de fraude. O DBSC vai lhe dizer "mesmo navegador do início da sessão, sim ou não", e nada mais. Sem reputação de dispositivo. Sem "este dispositivo está por trás de 50 contas". Sem vinculação entre contas. Sem score de risco. Mesmo onde o DBSC está totalmente implementado, você ainda precisa de uma camada separada de identificação de dispositivo, porque o DBSC se recusa a ser uma.
Cobertura: Chrome no Windows hoje
O DBSC está em disponibilidade geral no Chrome no Windows. O suporte para macOS via Secure Enclave ainda está por vir. O Edge fez um origin trial sem disponibilidade geral. Safari e Firefox não o estão lançando. No iOS Safari e no Firefox, isso é zero proteção.
O fingerprint da cside funciona em todos os navegadores, para cada visitante, sem amostragem. Ele vê a requisição real no caminho real, não importa o que cada fornecedor lance a seguir.
A realidade da implementação
O DBSC não é um botão. Cada site precisa rearquitetar sua camada de sessão no servidor: registro de chaves, endpoints de renovação, gestão do ciclo de vida e alternativas para navegadores sem suporte. Por isso, um trimestre depois da disponibilidade geral, a lista pública de partes dependentes é essencialmente Google e Okta.
O fingerprint da cside é uma integração direta no caminho de JavaScript de primeira parte já existente. O prazo é de semanas, não um programa de segurança de vários trimestres.
A diferença arquitetônica: primeira parte, sem amostragem, invisível para os atacantes
A cside coleta através do proxy de primeira parte no caminho de entrega do script. Disso decorrem duas coisas.
É sem amostragem e universal. Cada visitante real, sobre a carga real entregue a usuários reais, não uma fatia amostrada de um SDK que parte do tráfego nunca carrega.
É estruturalmente invisível para os atacantes. Não há uma origem de SDK de terceiros para procurar nem uma requisição separada para bloquear. Quando testamos grandes bancos e seguradoras dos EUA, a identificação de dispositivo deles rodava em primeira parte e permanecia invisível para o BuiltWith, o Wappalyzer e as varreduras estáticas padrão. Só uma renderização real no navegador a revelava.
O DBSC é o oposto por design: um protocolo público, bem documentado e detectável. Um atacante consegue ver exatamente quando o DBSC está em jogo e contornar os casos que ele não cobre, uma sessão no Safari, um fluxo antes do login, ou uma sessão recém-obtida por phishing no próprio dispositivo dele.
Controle do fornecedor
"É só usar o recurso do Google" significa terceirizar o seu roteiro de confiança de sessão para as decisões de design do Chrome e para navegadores que você não controla. A cobertura, o modelo de privacidade e o cronograma de lançamento são decididos em outro lugar. Uma camada independente do navegador que você possui mantém esse controle em casa.
A forma certa de usar DBSC e fingerprint juntos
A posição crível é complementar, não excludente.
Implemente o DBSC onde puder. É uma boa proteção gratuita contra o roubo de cookies no Chrome, e carrega um sinal maior: toda a indústria está caminhando para a confiança vinculada ao dispositivo. Isso valida a tese e costuma ampliar o orçamento para ela.
Depois cubra o que o DBSC estruturalmente não consegue: todos os navegadores, do pré-login ao checkout, a fraude entre contas, o abuso de bots e agentes de IA, a detecção de VPN e proxy e as evidências de chargeback. O DBSC chegar à disponibilidade geral não fecha essa lacuna. Reforça o argumento para fechá-la.
O que fazer esta semana
- Ative o DBSC onde sua stack e os navegadores dos seus usuários o suportarem. Trate-o como proteção gratuita contra roubo de cookies para Chrome no Windows, não como sua estratégia de confiança de sessão.
- Adicione uma camada de dispositivo independente do navegador que rode antes do login e entre contas, para que a fraude de cadastro, o credential stuffing e o roubo a partir de um dispositivo novo fiquem visíveis em todos os navegadores.
- Ligue uma divergência de dispositivo a uma ação. Um fingerprint que não corresponde à base estabelecida no login deveria disparar uma autenticação reforçada ou encerrar a sessão, não apenas registrar uma linha.
- Verifique sua cobertura fora do Chrome. Se os usuários de iOS Safari e Firefox não têm validação de sessão consciente do dispositivo, é aí que o próximo reuso vai cair.
Como a cside se encaixa
O fingerprint de dispositivo da cside coleta mais de 100 sinais de navegador, dispositivo e rede no caminho de primeira parte para construir um identificador persistente de cada visitante, em cada navegador. Funciona antes de existir uma sessão para vincular, liga dispositivos entre contas, pontua o risco e alimenta uma divergência no seu motor de regras ou provedor de identidade já existente.
O DBSC diz se o cookie voltou do mesmo dispositivo. A cside diz quem é o dispositivo, o que ele fez nas suas contas e se deve ser confiado, da primeira requisição até o checkout.
Em 2026-06-09. A disponibilidade do DBSC e o suporte dos navegadores estão mudando rapidamente; verifique o status atual do lançamento nas fontes do Google e dos fornecedores de navegadores antes de depender da cobertura.
Agende uma demonstração para ver como a cside cobre a fraude que o DBSC nunca foi criado para impedir.
