Uma simples falta de padronização pode virar uma brecha de segurança

Máscara A: ***.345.678-** Máscara B: 012.**5.6**-90 Resultado: 012.345.678-90

Recentemente vendi meu carro para uma revenda. Dias depois, recebi uma notificação no app da CNH Digital informando que o veículo já estava em processo de transferência. Até aí, tudo certo.

Mas ao abrir as notificações com mais atenção, notei algo curioso.

Na primeira tela, o campo CNPJ do comprador estava parcialmente suprimido com asteriscos. Ok. Boa prática. (inclusive esse campo deveria ser "CPF/CNPJ do comprador")

Mas horas depois recebi outra notificação, dentro do mesmo aplicativo, referente à Autorização de Transferência (ATPV-e). E aí começa o problema.

O campo nome, que antes estava totalmente visível, passou a aparecer suprimido. (suponho que na primeira tela também deveria estar suprimido)

Mas o campo CPF/CNPJ, que antes estava protegido, apareceu com outro padrão de mascaramento.

Ou seja: não existe um padrão consistente de anonimização.

Um simples "de-para" na regra de exibição já foi suficiente para expor informações de maneira diferente da primeira tela.

Em software, não basta mascarar dados. É preciso garantir que a regra seja única, centralizada e aplicada de forma consistente em todos os pontos do sistema.

Porque às vezes a vulnerabilidade não está em um hacker sofisticado. Está em uma inconsistência de interface.

Fica a reflexão para quem constrói sistemas que lidam com dados sensíveis: suas regras de proteção são realmente padronizadas ou cada tela implementa do seu jeito?

Observação: os dados da imagem foram alterados para preservar a integridade da pessoa envolvida.