TL;DR: DBSC versus fingerprint de dispositivo
- O que o DBSC cobre: o DBSC vincula uma sessão a chaves guardadas no hardware e é realmente forte para impedir o reuso de cookies roubados, mas hoje só funciona no Chrome em Windows, age apenas depois do login e foi deliberadamente projetado para não ser uma camada de identidade de dispositivo.
- Como o fingerprint do cside o complementa: o cside coleta mais de 250 sinais de navegador, dispositivo e rede no caminho first-party para criar um identificador persistente de cada visitante, em qualquer navegador, e funciona no cadastro, no login, no checkout e na redefinição de senha, onde o DBSC não tem nenhuma sessão para vincular.
- A decisão é sua: implemente o DBSC como proteção gratuita contra roubo de cookies no Chrome e depois decida se a fraude antes do login, o abuso entre contas e a reputação de dispositivo em todos os navegadores são brechas que você pode deixar abertas.
Sem tempo? Veja o fingerprint de dispositivo do cside. Ele cobre tudo o que está abaixo em uma única implementação.
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, sem origem de terceiros
A cside coleta a partir do seu próprio script first-party, dentro da sessão. 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.
Não há origem de terceiros para bloquear. Não há uma origem de SDK de fornecedor separada para procurar nem uma requisição separada para filtrar. 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 ataque pós-login que o DBSC abençoa é real, não teórico: veja como o device code phishing contorna a MFA e quais sinais a nível de sessão o detectam. 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 250 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.
