Checkers: como proteger APIs contra validação em massa de dados

A notícia do Abril.com.br sobre a operação da DRCI no Rio me chamou atenção por um detalhe técnico específico: os checkers. Não é só mais um caso de “vazamento de dados” — é uma indústria estruturada, com供应链 de ferramentas, bases de dados e até divisão de tarefas. Como dev, isso muda completamente a forma como você precisa enxergar segurança. Não basta proteger seu app. Você precisa entender que existe um ecossistema inteiro automatizando ataques contra o que você constrói.

Como o esquema criminoso realmente funciona — a visão técnica

O que a polícia apreendeu em Nova Iguaçu foi só a ponta. Segundo a reportagem, o esquema comercializava três coisas distintas: dados sigilosos, cartões clonados e checkers. Os dois primeiros são commodities — compram, vendem, esgotam. O terceiro é o que me preocupa como programador.

Checkers são softwares que testam automaticamente combinações de dados (CPF, data de nascimento, nome da mãe, número de cartão) contra APIs legítimas de bancos, fintechs e órgãos públicos. Eles funcionam porque a maioria dos sistemas de validação ainda aceita tentativas ilimitadas, ou porque os criminosos já comprometeram credenciais válidas de empresas tercerizadas.

Na minha experiência auditando APIs de clientes, vejo esse problema o tempo todo: endpoint de validação de CPF que retorna 200 OK para “CPF válido” ou 422 para “inválido”, sem rate limit, sem CAPTCHA, sem bloqueio por IP. Isso é um convite para um checker automatizar em massa.

A arquitetura por trás da venda de dados

O conglomerado de sites apreendido pela polícia segue um modelo de negócio clássico do underground:

• Camada 1 — Coleta: vazamentos de grandes empresas (LinkedIn, Facebook, brechas em ERPs) que alimentam bases brutas com bilhões de registros.
• Camada 2 — Enriquecimento: cruzamento de bases via checkers para validar quais dados estão realmente ativos (CPF válido + nome correto + banco onde a pessoa tem conta).
• Camada 3 — Comercialização: venda segmentada — “pacote CPF + banco + saldo aproximado” custa mais caro que dados crus.
• Camada 4 — Exploração: golpe do falso parente, empréstimo consignado fraudulento, clonagem de cartão.

O suspeito preso em Nova Iguaçu, de acordo com o Abril.com.br, era responsável por coordenar e manter parte dessa infraestrutura. As movimentações financeiras incompatíveis com o que ele declarava comprovam: o negócio é lucrativo.

Por que isso importa para você que programa

Toda vez que você sobe uma API sem rate limit, está essencialmente alimentando esse ecossistema. Não é exagero. Um único endpoint desprotegido pode validar milhares de CPFs por minuto para um checker que depois vende os resultados.

Três pontos que devo destacar:

1. LGPD não é burocracia — é defesa do seu produto. Vazamento = multa + quebra de confiança. Já atendi empresa que perdeu 40% da base após incidente público.
2. Dados que você coleta são responsabilidade sua. Aquele campo “telefone para SMS marketing” que parece inocente vira munição quando vaza.
3. APIs públicas são vitrine para atacantes. Cada endpoint seu é um alvo em potencial. Documente, mas não exponha o que não precisa.

Na Prática: como verificar se seus dados já estão no underground

Antes de falar de proteção, você precisa saber se já foi vítima. A ferramenta mais confiável que uso no dia a dia é a Have I Been Pwned, do Troy Hunt. Ela tem uma API gratuita que permite consultar de forma programática se um e-mail (ou senha) apareceu em vazamentos conhecidos.

Exemplo funcional em Python — script que eu rodava quando precisei auditar e-mails de uma base de clientes:

import hashlib
import requests

def check_email_pwned(email: str) -> int:
    """
    Consulta a API do Have I Been Pwned para verificar se o email
    aparece em vazamentos públicos conhecidos.
    Retorna a quantidade de vazamentos em que foi encontrado.
    """
    # A API espera o email em base64 na URL, mas a lib requests cuida disso
    url = f"https://haveibeenpwned.com/api/v3/breachedaccount/{email}"
    headers = {
        "hibp-api-key": "SUA_API_KEY_AQUI",  # necessária para uso em produção
        "user-agent": "yuri-audit-script"
    }
    response = requests.get(url, headers=headers, timeout=10)

    if response.status_code == 200:
        breaches = response.json()
        return len(breaches)
    elif response.status_code == 404:
        return 0
    else:
        raise Exception(f"Erro na API: {response.status_code}")

# Uso
emails_para_auditar = ["yuri@yurideveloper.com.br", "teste@empresa.com"]
for email in emails_para_auditar:
    qtd = check_email_pwned(email)
    if qtd > 0:
        print(f"⚠️  {email} aparece em {qtd} vazamentos")
    else:
        print(f"✅ {email} limpo")

Para verificar senhas (recomendo fazer em qualquer projeto novo), use o método k-anonymity da API — você envia só os primeiros 5 caracteres do hash SHA-1 e recebe de volta os sufixos vazados, sem expor a senha original:

import hashlib
import requests

def check_password_pwned(password: str) -> int:
    sha1 = hashlib.sha1(password.encode("utf-8")).hexdigest().upper()
    prefix, suffix = sha1[:5], sha1[5:]

    url = f"https://api.pwnedpasswords.com/range/{prefix}"
    response = requests.get(url, timeout=10)
    response.raise_for_status()

    for line in response.text.splitlines():
        hash_suffix, count = line.split(":")
        if hash_suffix == suffix:
            return int(count)
    return 0

# Exemplo
senha = "MinhaSenh@123"
ocorrencias = check_password_pwned(senha)
print(f"Essa senha aparece {ocorrencias} vezes em vazamentos.")

Esse último snippet é obrigatório em qualquer sistema de cadastro: bloqueia senha que já está em bases públicas. Não reinventa a roda — usa a melhor base de dados de senhas vazadas do mundo, mantida pelo Troy Hunt.

Erros comuns que devs cometem (e que alimentam esses esquemas)

São estes os deslizes que mais vejo em código de produção e que, somados, formam a vulnerabilidade explorada pelos checkers:

• Não implementar rate limiting em endpoints de validação. Um CPF não precisa ser validado 500 vezes por segundo pelo mesmo IP. Use Redis com TTL curto.
• Logs mal planejados que vazam dados sensíveis. Já vi sistema logando número de cartão inteiro para “facilitar debug”. Esse log vaza, vai para ELK, e alguém com acesso lê.
• Confiar só em JWT sem rotação. Token eterno é convite. Implemente refresh token e revogação.
• Armazenar senhas em MD5 ou SHA1 sem salt. Em 2026 isso ainda aparece em código legado. Migração urgente para bcrypt ou Argon2.
• Esquecer de validar origem em webhooks. Endpoint público que recebe callbacks precisa validar assinatura HMAC. Senão vira porta de entrada para fraude.
• Expor mais dados do que o necessário em respostas de API. O clássico { "user": { "cpf": "...", "saldo": ..., "limite": ... } } quando o cliente precisa só do nome.

Cuidado com a armadilha do “é só um sistema interno”. Sistemas internos hoje são SaaS, têm acesso à internet, e são alvos primários porque ninguém atualiza nem monitora.

O papel do desenvolvedor na LGPD — o que ninguém fala

Quando entrei para o mundo da conformidade, percebi que a maioria dos devs trata LGPD como tarefa do DPO. Não é. LGPD é engenharia. Cada coleta de dado precisa ter propósito declarado, retenção definida e mecanismo de exclusão.

Implementei em um projeto um sistema de data minimization onde o backend só retorna os campos que o frontend explicitamente pediu via GraphQL ou via whitelist no controller. Parece exagero, mas reduziu em 60% o volume de dados em logs e backups.

Se você quer ir além, considere:

FAQ — perguntas que devs realmente fazem

Como saber se minha aplicação está sendo usada como checker?

Monitore padrões anômalos: requests por segundo vindos de poucos IPs, alta taxa de erro em endpoints específicos, picos de tráfego em horários incomuns. Ferramentas como Datadog APM, New Relic ou até um dashboard em Grafana com Prometheus identificam isso em minutos.

Vale a pena usar uma API paga de validação de identidade?

Sim, na maioria dos casos. Empresas como Unico (ex-IDWall), ClearSale ou Datavalid custam poucos centavos por consulta e blindam seu sistema contra esse tipo de abuso. O custo é menor que uma fraude concretizada.

Checkers são ilegais de usar, mesmo “só para testar”?

Sim. Testar sistema alheio sem autorização é crime — tanto pela legislação brasileira (Lei 12.737/2012, a “Lei Carolina Dieckmann”) quanto pela maioria das jurisdições internacionais. Para testar seu próprio sistema, use ferramentas de pentest autorizado como OWASP ZAP, Burp Suite ou Nikto.

Se eu achasse meu CPF num desses sites, o que faço?

Registre B.O. online (qualquer estado aceita), comunique o banco onde tem conta, troque senhas, ative autenticação em dois fatores em todos os serviços, e peça inclusão no Cadastro Positivo de Fraudadores do SERASA. Em paralelo, entre com ação judicial pedindo indenização — a jurisprudência tem sido favorável.

Existe forma de impedir 100% esses esquemas?

Não. Mas dá para elevar o custo do ataque ao ponto de não compensar economicamente. É a filosofia do defense in depth: várias camadas, nenhuma perfeita, todas necessárias.

Considerações finais

A prisão do suspeito em Nova Iguaçu é importante, mas é só um efeito pontual. A infraestrutura criminosa descrita pelo Abril.com.br é replicável — outros vão ocupar o vácuo. Como devs, o impacto real que geramos é outro: é construir sistemas que tornem esse tipo de operação inviável tecnicamente.

Da próxima vez que for subir um endpoint de validação, lembre: você não está só escrevendo código. Está decidindo se vai facilitar ou dificultar o trabalho desse ecossistema. Escolha sabiamente.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.