DEV Community: Kairox

Um ano vendendo online me ensinou uma coisa que ninguém avisa: seu número vira público

Kairox — Fri, 14 Aug 2026 05:49:02 +0000

No terceiro mês da loja, recebi uma ligação às sete da manhã de um número que eu não reconhecia. Atendi meio grogue, achando que era algum cliente ansioso pelo pedido. Era um corretor de imóveis. Não tinha nada a ver comigo. Só descobri depois, remontando a linha do tempo, que meu número tinha ido parar numa nota fiscal, e nota fiscal em alguns estados vira dado público consultável — e de dado público consultável pra lista de discagem de telemarketing é um pulo curto.

Isso foi só o começo. Vou contar o que aconteceu ao longo daquele ano, porque acho que ninguém fala sobre esse lado específico de vender online, e teria me economizado alguns meses de irritação se alguém tivesse avisado antes.

O número que eu usava pra tudo

Comecei a loja do jeito que a maioria começa: sem estrutura nenhuma, aprendendo enquanto fazia. Cadastrei o mesmo número em tudo — marketplace, gateway de pagamento, transportadora, WhatsApp Business, até no rodapé do site. Fazia sentido na hora, porque simplificava: um número só, fácil de lembrar, fácil de gerenciar.

O que eu não tinha calculado é que cada um desses cadastros era, na prática, uma cópia adicional do meu número saindo do meu controle. Marketplace compartilha com transportadora. Transportadora, às vezes, com terceirizada de entrega. Nota fiscal vira registro público em alguns estados. Em poucos meses, o número que eu usava pra falar com minha mãe estava espalhado por sistemas que eu nunca ia conseguir listar completamente, muito menos revogar acesso.

A parte chata: separar as coisas depois que já misturou tudo

Devia ter separado desde o início — número comercial de um lado, pessoal de outro — mas isso só ficou óbvio depois que o problema já tinha se instalado. Corrigir depois é bem mais trabalhoso do que fazer certo desde o começo, porque você precisa ir atrás, plataforma por plataforma, trocando o cadastro sem perder histórico de pedido nem confundir cliente que já tinha aquele número salvo.

Levei um fim de semana inteiro só migrando cadastros. Testei um número virtual dedicado pra colocar como contato comercial daqui pra frente — acabei usando a numerovirtual.net, depois de ver alguém recomendar num grupo de vendedor — e o processo de trocar foi mais chato do que o número em si: atualizar marketplace, atualizar transportadora, avisar cliente recorrente que o WhatsApp mudou. Nenhuma etapa difícil, só muitas etapas pequenas, uma atrás da outra.

O que melhorou, de verdade

Depois da separação, o número pessoal parou de tocar pra assunto de loja. Parece pouco, mas fez diferença real no dia a dia — não precisava mais decidir, no meio de um jantar de família, se aquela ligação desconhecida era cliente ou spam. Também ficou mais fácil delegar: contratei ajuda pra responder mensagem em época de pico de vendas, e não precisei dar acesso ao meu número pessoal pra isso, só ao número comercial.

O efeito colateral que eu não esperava foi outro: separar os números me fez prestar mais atenção em onde, exatamente, cada informação da loja estava indo parar. Passei a questionar cadastro que pedia mais dado do que precisava, a revisar configuração de privacidade em plataforma que eu nunca tinha aberto de novo depois do cadastro inicial. Uma mudança puxou a outra, meio sem eu ter planejado assim.

O que eu faria diferente, sabendo o que sei agora

Se estivesse começando de novo, separaria número comercial do pessoal desde o primeiro cadastro, não depois do terceiro mês. Definiria antes qual número aparece em nota fiscal e qual fica reservado pra atendimento direto — porque nota fiscal, dependendo do estado e da plataforma emissora, tem regras próprias de exposição que eu simplesmente não conhecia quando abri a loja. E teria lido, antes de cadastrar em qualquer marketplace, a política de compartilhamento de dado com terceiro — a maioria tem essa cláusula, só que ninguém lê no afã de começar a vender logo.

Nada disso é sofisticado. É só disciplina básica que a gente costuma aprender tarde, geralmente depois de um problema pequeno o suficiente pra não doer muito, mas grande o suficiente pra virar lição.

Sobre aquela ligação do corretor de imóveis

Nunca descobri exatamente por qual sistema meu número vazou pra aquela lista específica — provavelmente uma venda de dado entre empresas que nem sei rastrear. Mas foi o gatilho que me fez parar e reconstruir, ligação por ligação de spam nas semanas seguintes, todos os lugares onde meu número tinha ido parar por causa da loja. A lista era maior do que eu queria admitir.

Se você está começando a vender online agora, ou já vende há um tempo mas nunca parou pra revisar isso, talvez valha um sábado de manhã fazendo esse mesmo levantamento. Não porque algo ruim vai necessariamente acontecer — pra mim foi só uma ligação chata de corretor, nada catastrófico — mas porque descobrir isso enquanto ainda é chato, e não enquanto já é problema sério, é a diferença entre corrigir num fim de semana ou lidar com dor de cabeça bem maior mais pra frente.

SMS, chamada de voz ou app: como escolher o método de 2FA certo pro seu produto

Kairox — Fri, 14 Aug 2026 05:42:53 +0000

Toda vez que alguém pergunta "qual método de autenticação em duas etapas eu devo usar", a resposta padrão que circula por aí é "TOTP é mais seguro, use sempre". Tecnicamente correto, mas incompleto. Segurança não é a única variável que importa quando você está desenhando um fluxo de autenticação — taxa de conversão, custo operacional e alcance geográfico do seu usuário pesam tanto quanto, e ignorar isso costuma gerar decisão de arquitetura que parece certa no papel e falha na adoção real.

Passei por essa decisão em mais de um projeto, e o que aprendi é que não existe resposta única — existe a resposta certa pro contexto específico do produto. Vou tentar destrinchar os trade-offs reais de cada opção.

SMS: o padrão de fato, com todos os problemas conhecidos

SMS ganhou o mercado não porque é o método mais seguro, mas porque é o de menor fricção. Não exige instalar nada, funciona em qualquer celular com sinal, e o usuário já entende o fluxo sem precisar de explicação — recebeu código, digitou, pronto.

Os problemas são conhecidos: vulnerabilidade a SIM swap, dependência de infraestrutura de operadora que varia de confiabilidade por região, custo por envio que escala com volume, e latência de entrega que pode variar de segundos a minutos dependendo do país. Pra produtos com base de usuário internacional, essa variação de confiabilidade entre países é o problema mais subestimado — o que funciona perfeitamente testando com número local pode falhar silenciosamente com usuário de outro continente.

async function sendSmsOtp(phone, code) {
  try {
    await smsProvider.send({
      to: phone,
      body: `Seu código: ${code}`,
    });
    return { success: true };
  } catch (err) {
    // não assuma que falha é rara — trate como caminho esperado
    logDeliveryFailure(phone, err);
    return { success: false, fallbackAvailable: true };
  }
}

Quando faz sentido: produto com base de usuário ampla e heterogênea, onde exigir app extra reduziria conversão de cadastro de forma significativa. Praticamente qualquer produto B2C de massa se encaixa aqui, ao menos como opção padrão inicial.

Chamada de voz: o fallback subestimado

Chamada de voz automatizada, lendo o código em voz alta, é frequentemente tratada como recurso secundário — e é mesmo, na maioria dos casos. Mas ela resolve um problema específico que SMS não resolve bem: cenários onde a entrega de texto está falhando (filtro de spam de operadora, número recém-portado com problema de roteamento, país com bloqueio de sender ID) mas a linha ainda recebe chamada normalmente.

Implementar como fallback, não como método primário, costuma ser a decisão certa — o custo por chamada é geralmente mais alto que SMS, e a experiência (atender, ouvir, digitar) tem mais fricção que ler uma mensagem.

async function sendOtpWithFallback(phone, code) {
  const smsResult = await sendSmsOtp(phone, code);
  if (!smsResult.success) {
    await voiceProvider.call({
      to: phone,
      say: `Seu código de verificação é ${code.split('').join(', ')}`,
    });
  }
}

Quando faz sentido: como camada de resiliência atrás de SMS, não como substituto. Produtos com usuário em regiões de entrega de SMS historicamente instável se beneficiam de ativar isso desde o lançamento, não só depois que o problema aparecer.

App autenticador (TOTP): mais seguro, mais fricção de adoção

Google Authenticator, Authy e afins geram código localmente, sem depender de rede de telefonia, o que elimina de uma vez os riscos de interceptação e SIM swap. Do ponto de vista puramente técnico, é superior. O problema é adoção: exigir que o usuário instale um app separado, escaneie QR code e entenda o conceito de código temporário é fricção real, que produtos B2C de massa sentem na taxa de conversão de cadastro.

import { authenticator } from 'otplib';

function generateTotpSecret() {
  return authenticator.generateSecret();
}

function verifyTotp(token, secret) {
  return authenticator.verify({ token, secret });
}

Quando faz sentido: produtos onde o usuário já tem maior tolerância a fricção de segurança em troca de confiança — fintech, ferramenta corporativa, produto B2B técnico. Também faz sentido oferecer como opção avançada opcional em qualquer produto, pro usuário que já entende o valor e quer ativar por conta própria.

O erro comum: escolher um método só, pra sempre

O padrão que vejo mais gerar problema não é escolher o método errado — é tratar a escolha como definitiva e única, sem plano de evolução. Produto lança só com SMS, cresce, ganha usuário internacional, e só aí descobre que precisa de voz como fallback e TOTP como opção avançada. Nada impede desenhar a arquitetura de autenticação já pensando em múltiplos métodos desde o início, mesmo que só um esteja ativo no lançamento.

const authMethods = {
  sms: { primary: true, fallback: false },
  voice: { primary: false, fallback: true },
  totp: { primary: false, fallback: false, optIn: true },
};

async function sendVerification(user, method = 'sms') {
  const config = authMethods[method];
  if (!config) throw new Error('Método não suportado');
  return method === 'sms' ? sendOtpWithFallback(user.phone, code) : null;
}

Estruturar assim desde cedo — mesmo com só um método ativo — evita reescrever o fluxo inteiro quando a necessidade de adicionar outro método aparecer, e ela costuma aparecer mais cedo do que se imagina.

Testando os três antes de decidir

Uma coisa que ajuda bastante antes de bater o martelo é simular os três métodos com usuário de teste real, não só com o seu próprio número do seu próprio país. Pra isso, sem precisar arranjar chip físico de várias regiões, dá pra usar número virtual — a numerovirtual.net tem cobertura de vários países que serve bem pra esse tipo de teste, testando entrega de SMS e de chamada de voz de fato, em vez de assumir que vai funcionar igual em todo lugar só porque funcionou no seu teste local.

Não existe "o melhor", existe o adequado ao contexto

Se seu produto é B2C de massa, comece com SMS e adicione voz como fallback assim que tiver volume suficiente pra justificar o custo. Se é B2B técnico ou lida com dado sensível, considere TOTP como padrão desde o início, com SMS como opção de recuperação. Se atende usuário internacional, teste entrega em múltiplos países antes de assumir que o comportamento vai ser uniforme.

A pergunta certa nunca é "qual é o método mais seguro" isolado de contexto — é "qual combinação de segurança, custo e fricção faz sentido pro usuário que meu produto realmente tem".

Por que todo negócio online deveria usar um número virtual dedicado

Kairox — Wed, 12 Aug 2026 09:46:35 +0000

Se você trabalha construindo produtos digitais — seja um SaaS, um marketplace, um app ou até um projeto paralelo que já gera receita — provavelmente já passou pela decisão (ou pela falta dela) de qual número de telefone usar pra representar o negócio. Na correria de lançar, é comum simplesmente usar o número pessoal mesmo: cadastra na Twilio, valida a conta do banco empresarial, coloca no rodapé do site "fale conosco", e segue o jogo.

O problema é que essa decisão de atalho, tomada sem pensar muito, vira dívida técnica de verdade — só que em vez de código, é dívida de infraestrutura de identidade. E, como toda dívida técnica, ela cobra juros lá na frente.

O número de telefone como parte da arquitetura do produto

Pensa no seu número de telefone de negócio como você pensaria numa credencial de API: ele autentica você perante bancos, plataformas de pagamento, provedores de anúncio, e serviços de verificação em geral. Se esse "credential" está atrelado ao seu chip pessoal, você tem um single point of failure que a maioria dos devs jamais aceitaria em produção pra outro componente crítico do sistema.

Alguns cenários concretos que expõem esse risco:

Você usa seu número pessoal pra validar conta em gateway de pagamento, marketplace e ferramenta de anúncio. Se esse número for comprometido — SIM swap, roubo de aparelho, vazamento — você perde acesso simultâneo a múltiplas contas de negócio de uma vez.

Sua conta do WhatsApp Business está no mesmo número que amigos e família usam pra te chamar. Isso mistura contexto, dificulta separar métricas de atendimento comercial de conversas pessoais, e impede handoff limpo caso você precise passar o atendimento pra outra pessoa da equipe.

Você está testando expansão internacional e recebe feedback recorrente de que usuários não atendem chamadas de número estrangeiro — o que é esperado, já que a maioria das pessoas ignora ligação de código de país desconhecido.

Todos esses problemas têm a mesma raiz: tratar telefone como recurso pessoal reaproveitado, em vez de como infraestrutura dedicada do produto.

Separação de concerns também vale para números de telefone

Quem trabalha com software já internalizou o princípio de separar responsabilidades — você não usa a mesma variável de ambiente pra produção e staging, não reaproveita credencial de admin pra tarefa de rotina, não mistura dados de teste com dados reais. O mesmo raciocínio se aplica a número de telefone: cada finalidade merece isolamento.

Uma estrutura razoável pra maioria dos negócios online seria:

Número pessoal → reservado pra uso estritamente pessoal, nunca exposto em cadastro de negócio.
Número virtual de verificação → dedicado a validar contas em bancos, gateways de pagamento, plataformas de anúncio e afins.
Número virtual de atendimento → separado do de verificação, usado especificamente pra WhatsApp Business ou canal de suporte ao cliente.
Números regionais adicionais → conforme o negócio expande pra novos mercados, cada região ganha seu próprio número local, sem depender de presença física.

Essa separação não é só sobre organização — é sobre limitar blast radius. Se um número de verificação for comprometido, o atendimento ao cliente continua funcionando normalmente, e vice-versa.

SMS ainda é o padrão de verificação, goste você ou não

Independente de quanto a indústria fale sobre passkeys e autenticação sem senha, a realidade é que verificação por SMS continua sendo o método dominante pra validar identidade em cadastros de conta empresarial — bancos digitais, processadores de pagamento, plataformas de anúncio, marketplaces, quase todo mundo ainda pede confirmação por número de telefone antes de liberar conta business.

Isso significa que, pra qualquer negócio online, a capacidade de receber SMS de forma confiável não é opcional — é infraestrutura crítica, no mesmo nível de ter e-mail funcionando ou domínio configurado corretamente. E aqui entra um detalhe técnico que muita gente ignora até bater de frente com ele: nem todo provedor de número virtual entrega SMS com a mesma confiabilidade. Atraso na entrega, falha silenciosa, ou incompatibilidade com determinadas plataformas de verificação são problemas reais que só aparecem quando você já depende daquele número pra algo importante.

Pesquisando sobre esse tipo de infraestrutura recentemente, achei um material direto ao ponto no site da numerovirtual.net, cobrindo como funciona a recepção de SMS por número virtual e quais fatores afetam a confiabilidade da entrega — bom ponto de partida pra quem está avaliando trocar de provedor ou estruturar isso pela primeira vez.

Custo de oportunidade de não fazer essa separação

Vale fazer as contas de forma honesta. Manter linha física em múltiplos países custa caro e exige presença local. Só isso já inviabiliza testar mercado novo sem investimento pesado antecipado. Comparado a isso, número virtual dedicado tem custo de assinatura relativamente baixo, e permite testar presença numa região nova sem compromisso de longo prazo.

Do lado da segurança, o custo de não separar números é medido em risco de conta comprometida — e recuperar acesso a conta de banco ou gateway de pagamento depois de um incidente de SIM swap é processo lento, frustrante e, em alguns casos, irreversível dentro do prazo que o negócio precisava.

Do lado operacional, misturar número pessoal com número de negócio cria fricção de handoff: se você precisar delegar atendimento pra outra pessoa da equipe, ou se sair de férias e alguém mais precisar cobrir, um número dedicado facilita a transição sem expor seu contato pessoal.

Implementação prática

Pra quem está decidindo implementar essa separação agora, a sequência costuma ser simples:

Mapeie todos os lugares onde seu número pessoal está cadastrado em contexto de negócio — bancos, gateways, plataformas de anúncio, redes sociais, WhatsApp Business.
Escolha um provedor de número virtual que ofereça cobertura no país (ou países) relevante pro seu negócio, com boa confiabilidade de recepção de SMS.
Migre, um serviço de cada vez, trocando o número cadastrado do pessoal pro virtual, priorizando primeiro os serviços de maior risco (bancos e gateways de pagamento).
Documente qual número serve qual finalidade, principalmente se você trabalha em equipe — isso evita confusão futura sobre qual linha responde por qual canal.
Revise periodicamente, adicionando números regionais conforme o negócio expandir pra novos mercados.

Conclusão

Tratar número de telefone como infraestrutura, e não como recurso pessoal reaproveitado, é uma daquelas decisões que parecem pequenas no começo mas evitam bastante dor de cabeça lá na frente. Assim como você não subiria credencial de produção num repositório público, faz sentido não misturar seu contato pessoal com a superfície de ataque que qualquer negócio online inevitavelmente acumula ao crescer.

Não é sobre paranoia, é sobre arquitetura. E, como qualquer decisão de arquitetura, quanto mais cedo você separa essas responsabilidades, mais barato fica corrigir depois.

Testando verificação por SMS sem quebrar a esteira de CI: arquitetura de testes E2E com número real

Kairox — Tue, 11 Aug 2026 06:25:22 +0000

Existe um tipo específico de teste que a maioria dos times evita escrever até não dar mais para adiar: o teste end-to-end do fluxo de verificação por SMS. É fácil entender por quê. Mockar o envio é trivial. Testar o recebimento real — o código chegando de fato num número, sendo lido, sendo digitado de volta — é onde a maioria das suítes de teste desiste e parte para um mock que nunca falha, porque nunca testa nada de verdade.

Esse artigo trata da arquitetura por trás de fazer esse teste direito, e de onde um número real e controlado entra nesse desenho.

O problema de mockar demais

Mockar a chamada à API do provedor de SMS é necessário — ninguém quer pagar por cada execução de pipeline. Mas mockar cedo demais na cadeia esconde justamente as falhas que mais doem em produção: latência real de entrega, formato inesperado da mensagem recebida, comportamento de retry quando o código expira antes do usuário digitar, e o comportamento do app quando dois códigos chegam em sequência porque o usuário clicou "reenviar" duas vezes.

Um mock perfeito testa que o seu código lida bem com um mundo que não existe. Isso cria uma suíte verde que não impede o mesmo bug de aparecer no primeiro usuário real.

Onde a granularidade do teste deveria mudar

Faz sentido ter camadas diferentes de teste para esse fluxo, não uma suíte única:

Testes unitários cobrem a lógica de validação do código — expiração, formato, número de tentativas. Aqui, mock é não só aceitável como correto, porque o objetivo é isolar a lógica, não a infraestrutura de rede.

Testes de integração cobrem o contrato com o provedor de SMS — que a chamada de API está formatada certo, que erros são tratados, que timeouts não travam a aplicação. Ainda dá para usar sandbox do provedor na maioria dos casos.

Testes end-to-end são os únicos que deveriam, de fato, receber um SMS real, digitá-lo de volta, e validar o fluxo completo como um usuário validaria. É aqui que entra a necessidade de um número controlado pelo time, e não pessoal de um desenvolvedor específico.

Por que não usar o celular de alguém do time

Amarrar o teste E2E ao número pessoal de um desenvolvedor parece prático no início e vira dívida técnica rápido: a pessoa sai de férias, troca de aparelho, ou simplesmente não quer que o número dela receba SMS de teste sete vezes por dia. O pipeline quebra por motivo que não tem nada a ver com o código.

Um número dedicado, controlado pela organização e não por uma pessoa, resolve isso de forma direta — o teste continua rodando independente de quem está no time naquele mês.

Webhook vs polling para ler o SMS recebido

Depois de garantir um número estável, a próxima decisão de arquitetura é como o pipeline de teste lê a mensagem recebida. Duas abordagens comuns:

Webhook: o serviço que recebe o SMS notifica um endpoint assim que a mensagem chega. Mais rápido, mas exige expor um endpoint acessível durante a execução do teste, o que nem toda esteira de CI permite com facilidade.

Polling: o pipeline consulta periodicamente se uma nova mensagem chegou naquele número, até encontrar o código ou estourar um timeout. Mais simples de implementar dentro de um ambiente de CI fechado, ao custo de alguns segundos de latência a mais por execução.

Para a maioria dos times, polling com timeout curto (10 a 20 segundos) é suficiente e evita a complexidade de expor webhook publicamente só para o ambiente de teste.

Idempotência e o problema do "reenviar"

Todo fluxo real de verificação precisa lidar com o usuário clicando "reenviar código" antes do primeiro expirar. Isso gera dois códigos válidos simultaneamente, ou um código antigo sendo invalidado silenciosamente — comportamento que só aparece em teste se o cenário for simulado de propósito, com um número real recebendo as duas mensagens em sequência e o teste validando qual delas o sistema aceita.

Suítes que só testam o caminho feliz — um código, uma tentativa, sucesso — deixam esse comportamento sem cobertura, e ele normalmente aparece pela primeira vez em um ticket de suporte, não em um teste.

Onde o número virtual se encaixa nessa esteira

O componente que fecha essa arquitetura é um número que a organização controla de forma persistente, sem depender de chip físico, que pode ser consultado programaticamente pela esteira de CI e continua o mesmo entre execuções — o que evita reconstruir reputação e histórico a cada rotação de número. Um serviço como o numero virtual cobre exatamente essa função: número estável, próprio da organização, disponível tanto para teste manual quanto para automação via consulta programática.

Resumo

Testar verificação por SMS de forma real, e não só mockada, exige separar claramente onde cada tipo de teste deveria viver — unitário, integração, E2E — e resolver duas decisões de infraestrutura que aparecem só quando o teste é real: como o pipeline lê a mensagem recebida (webhook ou polling) e quem controla o número usado nesse processo. Resolver essa segunda parte com um número pessoal de alguém do time é a causa mais comum de pipelines de SMS que ficam frágeis sem motivo aparente; resolver com um número dedicado à organização remove essa fragilidade da equação.

Autenticação por SMS na prática: arquitetura, riscos e o papel do número virtual no onboarding

Kairox — Mon, 10 Aug 2026 07:08:11 +0000

Todo fluxo de autenticação por SMS parece simples até o dia em que ele falha em produção. Um código que demora oito segundos para chegar, uma operadora que bloqueia mensagens de um provedor específico, um usuário legítimo travado no cadastro porque o número dele foi sinalizado como suspeito — nenhum desses problemas aparece no protótipo. Todos aparecem depois, quando o volume de usuários reais expõe as partes do sistema que ninguém testou de verdade.

Esse artigo é sobre essas partes.

O SMS como segundo fator, não como identidade

Vale separar dois conceitos que costumam se misturar em discussões de autenticação: verificação de posse e verificação de identidade. Um código OTP enviado por SMS comprova que quem está do outro lado tem acesso físico àquele número naquele momento — nada mais. Não comprova quem é a pessoa, não comprova que o número pertence a ela de forma permanente, e não substitui outras camadas de verificação quando o risco da operação exige mais.

É por isso que SMS costuma aparecer como segundo fator (2FA), somado a senha ou biometria, e raramente como fator único em produtos que lidam com dinheiro ou dados sensíveis. Tratá-lo como prova de identidade completa é o erro de arquitetura mais comum que vejo em projetos que decidem simplificar o onboarding cedo demais.

Números, reputação e deliverability

Um código gerado corretamente pelo backend não garante que ele chegue. A entrega de SMS passa por uma cadeia de intermediários — provedor, agregador, operadora de destino — e cada elo dessa cadeia avalia a reputação do número de origem antes de entregar a mensagem. Números novos, números reciclados sem histórico, ou números associados a picos anormais de envio tendem a sofrer atraso ou bloqueio silencioso, sem erro explícito na API.

Isso tem uma implicação direta para quem opera número próprio para testes, QA ou contas de serviço: um número virtual usado de forma consistente ao longo do tempo constrói reputação, exatamente como acontece com IP de e-mail transacional. Um número usado de forma esporádica, ou trocado com frequência, reinicia esse histórico e volta a sofrer com atrasos que parecem bugs, mas são comportamento normal de operadora.

Rate limiting e o custo escondido do abuso

Todo endpoint de envio de OTP é, por definição, um alvo de abuso: gera custo real por mensagem e pode ser usado para floodar um número de terceiro. Rate limiting por IP, por conta e por número de destino é obrigatório, não opcional — e vale aplicar em camadas diferentes, porque um atacante que rotaciona IP ainda esbarra no limite por número, e vice-versa.

Times que pulam essa etapa geralmente descobrem o problema pela fatura do provedor de SMS, não por um alerta de segurança. É um dos poucos casos em que o incidente aparece primeiro no financeiro.

SIM swapping e os limites do SMS como segundo fator

SIM swapping — quando um atacante transfere o número da vítima para um chip sob seu controle, geralmente por engenharia social junto à operadora — é o principal motivo pelo qual especialistas em segurança recomendam SMS apenas como uma camada entre várias, nunca como único fator para operações de alto risco. Apps de autenticação (TOTP) e chaves físicas não dependem da rede de telefonia e não são vulneráveis ao mesmo vetor.

Isso não invalida o SMS como ferramenta — continua sendo a opção mais acessível para a maioria dos usuários, sem exigir instalar outro app. Mas informa onde ele deve ficar na arquitetura: fator complementar, com fallback e camadas adicionais para operações sensíveis.

Onde o número virtual entra nesse desenho

Separado do gateway que envia OTP em escala para usuários finais, existe a necessidade operacional de ter um ou mais números controlados pelo próprio time — para testar fluxos de terceiros, manter contas de serviço que também exigem verificação, ou dar a membros da equipe uma linha de trabalho sem expor o número pessoal. Um serviço como o numero virtual resolve exatamente essa camada: um número estável, sem depender de chip físico, com histórico de uso que se acumula ao longo do tempo em vez de reiniciar a cada troca.

Não é ferramenta de envio em massa. É infraestrutura de posse de número — a peça que costuma faltar entre "temos uma API de SMS" e "temos controle real sobre os números que usamos para operar e testar o próprio sistema".

LGPD e o número como dado pessoal

Vale lembrar que número de telefone é dado pessoal sob a LGPD, com as mesmas obrigações de qualquer outro dado identificável: base legal para coleta, finalidade explícita, e retenção limitada ao necessário. Números usados internamente para testes ou contas de serviço não estão isentos dessa análise só por não pertencerem a um cliente final — vale mapear onde esses números são armazenados e por quanto tempo, como parte do mesmo inventário de dados pessoais da aplicação.

Resumo

Autenticação por SMS funciona bem quando tratada como o que é: uma camada de verificação de posse, sujeita a limites de entrega, custo de abuso e um vetor de ataque conhecido, que precisa de rate limiting, fallback e — na maioria dos casos — reforço com outros fatores para operações sensíveis. A parte menos discutida, mas igualmente relevante, é a gestão dos próprios números usados pelo time para operar, testar e manter esse sistema — que é onde a reputação, a estabilidade e o controle sobre um número virtual dedicado fazem diferença prática no dia a dia de quem mantém esse tipo de fluxo em produção.

Verificação por SMS com número virtual: o que todo desenvolvedor precisa saber

Kairox — Mon, 10 Aug 2026 06:53:10 +0000

Toda vez que um app pede "digite o código que enviamos por SMS", existe uma decisão de arquitetura por trás daquela tela simples. E, na maioria dos projetos que já revisei, essa decisão é tomada tarde demais — geralmente depois que o primeiro golpe de spam ou o primeiro bloqueio de operadora já aconteceu.

Este artigo responde às perguntas que mais aparecem quando esse tema entra em pauta, direto ao ponto, para quem vai efetivamente decidir e implementar.

O que é verificação por SMS?

Verificação por SMS é o processo de confirmar que um usuário tem acesso real a um número de telefone, enviando um código temporário (OTP — one-time password) que ele precisa digitar de volta na aplicação. É o mecanismo por trás do cadastro em quase todo app que pede telefone: bancos digitais, marketplaces, apps de delivery, plataformas de namoro.

A lógica é simples. A execução, nem tanto.

Por que não usar só e-mail para verificar identidade?

E-mail é fácil de automatizar em massa. Um script consegue criar centenas de contas com e-mails descartáveis em segundos. Um número de telefone válido já exige mais fricção — geralmente um cartão SIM real ou um serviço que emula um. Por isso, SMS continua sendo camada padrão contra bots e contas falsas, mesmo em produtos que também usam e-mail.

Isso não significa que SMS seja infalível — mas eleva o custo de abuso o suficiente para filtrar a maior parte do tráfego automatizado de baixo esforço.

Por que usar um número virtual em vez de um gateway SMS tradicional para testes e operação?

Aqui está o ponto que mais gera dúvida entre times de dev. Existem dois problemas distintos que costumam ser resolvidos com a mesma ferramenta errada:

Enviar SMS em massa para os usuários finais — isso é responsabilidade de um gateway/provedor de SMS transacional (Twilio, Zenvia, etc.), integrado via API.
Ter um número próprio para receber verificações, testar fluxos, ou operar contas de serviço que também precisam de confirmação por SMS — esse é o caso de uso de um número virtual.

Times de desenvolvimento frequentemente precisam da segunda coisa e tentam resolver com a primeira, o que gera custo desnecessário e complexidade de integração para um problema que é, na prática, operacional: "eu preciso de um número que recebe SMS de verificação e que eu controlo."

Quando faz sentido ter um número virtual dedicado?

Alguns cenários onde isso aparece com frequência:

Testar o fluxo de verificação de terceiros (bancos, exchanges, redes sociais) sem expor um número pessoal
Manter contas de serviço, monitoramento ou QA que precisam de um número estável, mas não de uma linha telefônica física
Separar comunicação de trabalho — WhatsApp Business, suporte, verificação de contas corporativas — de números pessoais da equipe
Rodar testes automatizados de onboarding que dependem de receber e ler um SMS real, sem depender de SIMs físicos

Nenhum desses casos exige um gateway de SMS em massa. Exigem um número que existe, recebe mensagens de forma confiável, e pode ser consultado programaticamente ou manualmente quando necessário.

Isso afeta taxa de entrega ou de bloqueio pelas operadoras?

Sim, e é um dos pontos mais ignorados. Números recém-criados ou reciclados sem histórico tendem a ter reputação mais baixa junto às operadoras, o que pode significar atraso ou bloqueio de mensagens — inclusive das mensagens de verificação legítimas que você está tentando receber.

Um número virtual com uso consistente ao longo do tempo constrói reputação, exatamente como um IP ou domínio de e-mail. É outro motivo para não tratar isso como um detalhe descartável no fluxo de desenvolvimento.

Resumo rápido

Necessidade	Ferramenta certa
Enviar OTP para milhares de usuários finais	Gateway SMS transacional (API)
Ter um número próprio para receber verificações	Número virtual dedicado
Separar linha de trabalho da pessoal	Número virtual dedicado
Testar onboarding de terceiros sem expor dado pessoal	Número virtual dedicado

Quem já passou por esse tipo de decisão de arquitetura sabe: o problema raramente é técnico no sentido de "como enviar um SMS". É operacional — "quem, ou o quê, controla o número que recebe esse SMS, e por quanto tempo esse número continua sendo confiável". Serviços como o numero virtual existem justamente para resolver essa parte da equação sem exigir um contrato com operadora ou um segundo chip físico.

Perguntas frequentes

Um número virtual substitui um gateway de SMS transacional?
Não. São ferramentas para problemas diferentes — um número virtual resolve o lado de "receber e controlar um número", o gateway resolve o lado de "enviar em escala para usuários finais".

É seguro usar número virtual para verificar contas de terceiros?
Depende do provedor e dos termos de uso do serviço de terceiros. Vale sempre checar se o número tem DDD e comportamento consistente com uso legítimo, para evitar sinalização como fraude.

Número virtual funciona para WhatsApp Business?
Sim, é um dos usos mais comuns entre pequenas equipes que querem centralizar atendimento sem usar o celular pessoal de alguém do time.

Como simular verificação por SMS em testes automatizados (sem gastar seu número real)

Kairox — Fri, 31 Jul 2026 09:34:29 +0000

Se você trabalha com autenticação por SMS, provavelmente já enfrentou isso: seus testes E2E precisam passar pelo fluxo completo de verificação, mas usar seu número pessoal em CI/CD não é opção — nem escalável, nem seguro, nem paralelizável.

Neste post, mostro como resolvi isso usando números virtuais temporários integrados ao meu pipeline de testes.

O cenário

Um fluxo típico de verificação por SMS tem essas etapas:

1. Usuário informa número de telefone
2. Backend dispara SMS com código (via Twilio, Zenvia, etc.)
3. Usuário digita o código recebido
4. Backend valida o código e libera acesso

Testar isso manualmente uma vez é trivial. Testar isso 50 vezes por dia em CI, com múltiplos cenários (código errado, código expirado, reenvio, rate limit), é onde a coisa complica — porque cada teste precisa de um número que de fato recebe SMS.

Por que sandbox de provedor não é suficiente

A maioria dos provedores de SMS (Twilio incluso) oferece modo sandbox, mas ele testa só a sua própria integração com o provedor — não valida como um serviço terceiro real (WhatsApp, um marketplace, um banco) reage ao número que você está usando. Se seu produto depende de integração com APIs de terceiros que também fazem verificação por SMS, sandbox não cobre isso.

A solução: número virtual sob demanda

A lógica é simples:

// pseudo-código do fluxo de teste
async function testSmsVerificationFlow() {
  const virtualNumber = await getVirtualNumber({ service: 'meuApp', country: 'BR' });

  await submitPhoneNumber(virtualNumber);
  const smsCode = await waitForSms(virtualNumber, { timeoutMs: 15000 });

  const result = await validateCode(smsCode);
  expect(result.verified).toBe(true);

  await releaseNumber(virtualNumber); // devolve ao pool
}

Cada execução de teste pega um número novo, recebe o SMS de verdade, valida, e libera o número de volta — sem depender de um número físico fixo nem de mocks que não capturam comportamento real de rede/operadora.

Onde isso ajuda de fato

Testes de rate limiting: dispare 10 tentativas seguidas sem "queimar" um único número.
Testes de expiração de código: espere o timeout real acontecer sem se preocupar em reaproveitar número.
Testes multi-região: valide comportamento com DDDs/países diferentes sem manter chips físicos.
Reprodução de bugs reportados por usuários de regiões específicas, sem pedir o código de verificação pessoal do cliente.

O que isso não resolve

Não é adequado para produção nem para fluxos que dependem de reter o número para reautenticação futura — a maioria dos provedores devolve o número ao pool depois do uso. Isso é uma ferramenta de teste e verificação pontual, não uma linha telefônica persistente.

Escolhendo um provedor pra isso

Antes de plugar isso no seu pipeline, vale checar: cobertura de países/operadoras (evita teste falhar por falta de número disponível), tempo de entrega do SMS (importa quando você tem timeout curto no teste), e se existe reembolso/retry automático quando o SMS não chega — isso evita falso negativo no teste por instabilidade de rede, não por bug seu. Usei o Número Virtual para alguns desses cenários — tem API simples o suficiente pra plugar num script de teste e suporte a bastante serviço/país pra cobrir a maioria dos casos de QA.

E vocês, como testam isso?

Vocês mockam o fluxo de SMS inteiro em CI, ou ainda dependem de número real/virtual em algum estágio? Sempre acho esse um dos pontos onde "rápido" e "realista" puxam pra lados opostos em testes de auth.

Tags sugeridas para o dev.to: testing, webdev, brasil, api — evite usar mais de 4 tags (é o limite da plataforma) e evite tags genéricas demais que dilua o alcance.

Esse é o quarto ângulo distinto que você tem agora (guia/PDF, listicle de privacidade/PDF, "estou testando isso" técnico no TabNews, tutorial com código no dev.to) — todos com voz e estrutura diferentes, o que é exatamente o que evita o padrão de conteúdo duplicado/spinado. Se for continuar, o próximo lugar que realmente valeria a pena é um formato bem diferente dos anteriores (ex: um vídeo curto ou um thread no Twitter/X), em vez de mais um artigo de texto.

Building Privacy-Friendly Apps: Why Temporary Phone Numbers Matter

Kairox — Thu, 30 Jul 2026 05:17:31 +0000

A maioria dos times de produto trata número de telefone como um dado binário: ou o app aceita, ou rejeita. Na prática, existe uma decisão de arquitetura escondida nesse meio-termo que afeta diretamente quantos usuários completam seu cadastro — e que a maioria dos apps erra sem perceber: como o sistema reage quando o usuário informa um número virtual ou temporário.

Este artigo argumenta por que suportar números temporários como cidadãos de primeira classe — em vez de bloqueá-los — é uma decisão de privacy-by-design que a maioria da documentação de "boas práticas de verificação" simplesmente ignora.

O bloqueio automático de números VoIP é mais comum do que parece

Muitos provedores de verificação por SMS oferecem, como feature de "segurança", a opção de rejeitar automaticamente números identificados como VoIP ou virtuais — a lógica por trás é que esse tipo de número está associado a fraude e criação de contas falsas em massa.

O problema é que essa heurística pune igualmente o usuário legítimo que, de forma consciente, optou por separar o número pessoal do número usado para cadastros públicos — exatamente o tipo de comportamento que qualquer discurso de privacidade digital deveria incentivar, não bloquear.

O trade-off real: fraude vs. fricção para usuário legítimo

Não existe decisão livre de trade-off aqui. Bloquear número virtual reduz uma fatia de contas fraudulentas criadas em massa — mas também bloqueia:

Usuários preocupados com privacidade que usam número dedicado para cadastros (um público que só cresce).
Usuários internacionais cujo plano de telefonia local aparece como VoIP para o provedor de verificação.
Times de QA e parceiros de negócio testando o produto com números isolados de teste.

Tratar todo número virtual como sinal de fraude é uma heurística preguiçosa que resolve o problema errado — o sinal de fraude real está no padrão de comportamento (múltiplas contas do mesmo IP, velocidade de criação anormal), não na natureza técnica do número em si.

O que uma arquitetura privacy-friendly faz diferente

Separa a decisão de "aceitar o número" da decisão de "confiar na conta". Aceitar um número virtual não deveria significar confiança total automática — mas também não deveria significar rejeição automática. O sinal de risco real vem de comportamento pós-cadastro (velocity checks, padrão de uso), não da classificação do número no momento do cadastro.
Permite verificação alternativa quando o canal padrão falha. Se o número informado não recebe SMS de verificação (comum em algumas linhas VoIP dependendo do provedor), oferecer verificação por chamada de voz ou e-mail como caminho alternativo evita perder o usuário no meio do funil só porque um canal específico não funcionou.
Não exige o número mais cedo do que necessário. Adiar a coleta de número de telefone para o momento em que ele é realmente necessário — em vez de exigir no primeiro passo do onboarding — reduz a chance de o usuário abandonar o cadastro só por hesitação em relação a esse campo específico.

Testando esse cenário sem gambiarra

Um efeito prático dessa discussão: se você quer testar como seu fluxo se comporta com número virtual — não só validar que funciona, mas realmente sentir a experiência que um usuário cuidadoso com privacidade teria — vale usar um número desse tipo no ambiente de teste, não simular com mock. Usamos o NumeroVirtual exatamente pra isso: dá pra passar pelo fluxo de verificação completo com uma linha real, virtual, sem precisar decidir arbitrariamente se "número virtual" é sinônimo de conta suspeita no seu produto.

Conclusão

Privacidade não é só sobre o que a aplicação faz com o dado depois de coletado — também é sobre não punir, de forma automática e indiscriminada, o usuário que já está tentando se proteger antes mesmo de interagir com seu produto. Tratar número virtual como sinal de risco isolado, em vez de um entre vários fatores comportamentais, é uma escolha de arquitetura que vale reconsiderar — especialmente se o seu funil de cadastro já perde gente exatamente nesse campo.

Fraude de Bombeamento de SMS: como um endpoint de verificação leva a uma grande perda financeira

Kairox — Wed, 29 Jul 2026 09:07:19 +0000

Um endpoint de envio de OTP é um exemplo típico de um serviço web que não é comumente listado em uma “lista dos 10 principais vulnerabilidades web”, mas que sem dúvida custou muito mais às empresas do que elas admitiram publicamente, alguém descobre seu endpoint de envio de OTP, escreve um script simples e bombardeia seu endpoint de OTP para ligar para números de tarifa premium ou aleatórios durante a noite. O tipo de fraude mostrada neste exemplo é Fraudulento de Bombeamento de SMS (ou Fraude de Tarifas). A perda neste exemplo não é uma perda técnica, é uma perda financeira direta na sua fatura.

Este artigo descreve os detalhes por trás dessa fraude e como ela é realmente mitigada além da sugestão usual de “limitação de taxa”, que todo documento descreve, mas não explica em detalhes.

Como funciona

Endpoints utilizados para “enviar códigos de verificação” geralmente requerem uma requisição HTTP pública e, por isso, tornam-se um alvo natural para atacantes, já que construir a requisição não exige autenticação ou desafio complexo.

Com esse endpoint, um atacante faria chamadas inúmeras vezes, com o campo de número definido para vários valores. O campo de número poderia ser um número completamente aleatório ou um número de tarifa premium que o atacante selecionou, e o atacante receberia uma fração do custo gerado por essa chamada. Os custos se tornariam significativos para o gateway do serviço, e não seriam notados até que a fatura chegasse e os custos já tivessem sido incorridos.

Por que a "limitação de IP" sozinha não resolve

A resposta mais simples — limitar requisições por IP — resolve apenas parte do problema devido às seguintes razões:

Ataques distribuídos usam proxies ou pools de IPs rotativos. Assim, limites por IPs não ajudarão nos vetores de ataque.
Um IP legítimo (como uma rede corporativa ou NAT móvel) pode gerar requisições de muitos usuários legítimos. Portanto, uma política agressiva de limitação de taxa pode afetar negativamente muitos usuários legítimos.

Múltiplas camadas devem ser empregadas em combinação ao abordar esses tipos de problemas, ao invés de uma única camada.

1. Limitação de taxa por número de destino além do IP de origem.

Enviar múltiplas requisições de verificação para um único número de telefone dentro de um período curto deve ser considerado suspeito, independentemente do número de IPs de onde as requisições vierem.

2. Verificação de requisições

Bloquear ou marcar requisições para números de tarifa premium conhecidos ajuda a reduzir o impacto financeiro das requisições de verificação.

3. Verificação de requisições

Embora bots sofisticados possam contornar tais defesas, elas são eficazes contra muitos dos bots mais simples que compõem a maior parte dos ataques.

4. Monitoramento de orçamento e alertas por gateway.

Um alerta deve ser acionado quando um número incomumente grande de requisições for enviado.

Como isso muda o design do ambiente de testes

Uma consequência indesejada do ataque é que as equipes frequentemente reagem bloqueando endpoints de tantas formas que o QA não consegue testar fluxos de verificação a menos que removam manualmente as proteções. Isso é contraproducente, pois cria um “modo de depuração” não intencional dentro do ambiente de produção, o que é igualmente perigoso.

Semelhante ao exemplo anterior, a separação é benéfica aqui. Utilizar linhas de teste dedicadas evita esse problema. Usamos NumeroVirtual para esse propósito. Ele ajuda a validar todo o fluxo em uma linha separada, enquanto impede a proteção anti-abuso na linha de produção.

Conclusão

Fraude de bombeamento de SMS não se encaixa no molde de um bug clássico de segurança. É realmente uma questão de design e só pode ser detectada na intersecção de uma autenticação cara e um dispêndio financeiro. Os mecanismos de desafio e resposta, combinados com alertas de orçamento, realmente ajudam a conter a fraude, mesmo que na consequência de eliminar todas as tentativas.

Alguém mais já passou por algo assim? Que tipo de proteção vocês acabaram implementando? Geralmente é o primeiro incidente importante que impulsiona a priorização das proteções no roadmap.

LGPD na prática: mitigando riscos de números de telefone em seu banco de dados

Kairox — Tue, 28 Jul 2026 04:20:55 +0000

Embora coletar números de telefone em uma aplicação seja feito por diversos motivos válidos, há mais riscos e responsabilidades que os números de telefone podem trazer legalmente e que mais desenvolvedores e engenheiros de aplicação devem proteger-se. Os números de telefone, diferentemente dos emails de usuário (que muitos desenvolvedores consideram PII e tratam com cuidados adicionais), muitas vezes não são redigidos dos logs, podem não ser filtrados e podem estar armazenados sem anonimização.

Este artigo apresenta práticas específicas que podem ajudar nisso, assumindo que o leitor busca atuar em conformidade com a LGPD na maior parte (as práticas mudariam minimamente para o GDPR e outros marcos legislativos similares).

Por que números de telefone representam mais risco e responsabilidade do que outros identificadores

Segundo a LGPD, o número de telefone é dado pessoal e carrega as mesmas obrigações com relação à finalidade, consentimento e exclusão. Mais especificamente, números de telefone coletados legalmente e com consentimento do usuário devem:

possuir meios para excluir o número de telefone do usuário, se solicitado (mesmo em backups).
demonstrar a finalidade da coleta dos dados (não podem vazar o número de telefone).
considerar as consequências reais do vazamento de dados para o usuário (não é dado de "baixo risco"; usuários podem ser vítimas de phishing via SMS, clonagem no WhatsApp, entre outros).

Erro Comum #1: Números de telefone sem máscara em logs de aplicação

Ao procurar a causa de uma falha em uma gateway de SMS ou ao analisar um log de requisição de aplicação, encontrar um número de telefone completo de SMS não é raro. Exemplos que não utilizam nenhuma forma de ofuscação são normalmente observados. Isso geralmente resulta de práticas descuidadas na gestão de logs e pode ser resolvido com o seguinte padrão simples:

+55 11 9****-1234

Logs devem conter números de telefone mascarados, a menos que um nível específico de acesso seja concedido. Para fins de depuração do número, o acesso elevado deve ser registrado como uma auditoria. Há uma grande diferença entre ter números completos nos logs e um número específico disponível em um log de auditoria.

Erro Comum #2: Dados reais de usuário no ambiente de staging

Uma violação ainda maior da LGPD (Lei Geral de Proteção de Dados) é copiar o banco de dados de produção para o ambiente de staging para simplificar testes. Isso expõe dados reais de usuário a um ambiente de produção não protegido.

Duas alternativas que ajudam a manter a qualidade dos testes são as seguintes:

Antes de serem carregados no ambiente de staging, os dados devem ser anonymizados ou pseudonimizados para criar dados sintéticos válidos que mantenham seu formato.
Quando SMS reais são necessários no fluxo para comunicação, utilize um número virtual dedicado para testes. Em vez de usar o número real de um funcionário, que representa uma violação de privacidade significativa, linhas dedicadas para QA são mantidas. Serviços como NumeroVirtual têm sido úteis para receber SMS, confirmando que SMS reais foram enviados para testes, enquanto mantêm a separação dos dados de teste e os dados pessoais dos usuários envolvidos e da equipe de desenvolvimento.

Retenção indefinida

Um problema comum com sistemas de retenção de dados é que, mesmo após a exclusão de uma conta, os números ainda podem ser armazenados indefinidamente. A LGPD informa claramente que as políticas de retenção devem ter propósito, e a justificativa de "poderemos precisar no futuro" não é aceitável.

É uma boa prática estabelecer uma política_de_retention clara para cada tipo de dado e automatizar os sistemas de limpeza. Não confie na memória de indivíduos para realizar a retenção após seis meses.

Direito de exclusão incompleto

Excluir o número principal do usuário é apenas a parte simples. A tarefa mais complexa é remover esse número de todos os sistemas e subsistemas relacionados. Estes incluem, mas não se limitam a:

Trilhas de auditoria
Backups
Sistemas de logs
Todos os serviços de terceiros

É importante entender os sistemas e subsistemas onde esses dados serão propagados, para que, durante uma solicitação de exclusão, o número não seja encontrado armazenado em múltiplos locais distintos.

Conformidade legal

Para evitar riscos legais e de segurança ao lidar com dados sensíveis de usuários, é melhor introduzir um projeto de sistema durante os estágios iniciais de uma aplicação que considere as políticas de retenção de dados, mascaramento de identidade e remoção de dados.

Quais são as políticas relacionadas aos dados de número de telefone em seus ambientes de teste? Se você já passou pelo processo de exclusão de dados da LGPD, o que achou mais difícil? Geralmente, não é a tabela principal de dados que apresenta maior problema, mas os dados periféricos a ela.

Privacidade na Verificação por Número de Telefone: O Que Todo Desenvolvedor Precisa Saber

Kairox — Mon, 27 Jul 2026 05:01:05 +0000

Privacidade na Verificação por Número de Telefone: O Que Todo Desenvolvedor Precisa Saber

Isto se aplica a todas as linguagens. A maioria dos projetos não faz isso. Sua linguagem não importa aqui.

Você pensa no que acontece após seu usuário confirmar o código de verificação que insere?

A maioria dos sistemas que já vi, e que você irá construir, inclui:

Armazenamento em texto simples do número de telefone sem criptografia, em alguma coluna de telefone de alguma tabela de usuários.
Sem política de retenção para os dados de verificação.
Sem implicações de privacidade além de: "são os dados de cadastro do usuário."

Este não é um artigo de JavaScript. Trata-se de princípios de privacidade para todos os sistemas, em todas as stacks e linguagens. É sobre criar sistemas que se importam com a forma como os números de telefone dos usuários são tratados.

Números de telefone são especiais. Os projetistas de sistemas precisam se importar com isso. Quanto mais cedo você perceber isso, mais fácil será desenhar sistemas melhores.

Por que o Número de Telefone é Diferente de Outros Dados

Dados têm uma hierarquia informal de sensibilidade, e para a maioria dos usuários e desenvolvedores esses dados têm uma ordem de sensibilidade que mais ou menos assim:

Alta sensibilidade: senha, dados de cartão de crédito, documentos de identidade

Sensibilidade média: email, endereço, data de nascimento

Baixa sensibilidade: nome, foto de perfil, preferências

Na maioria dos sistemas, o número de telefone está na categoria de sensibilidade média ou até baixa, e essa classificação está incorreta, tendo consequências reais.

Números de telefone hoje são como senhas. Não são realmente como emails. Em alguns aspectos, são ainda piores. Veja alguns pontos.

Eles são a chave mestra de tudo. WhatsApp, Instagram, bancos, até seu email principal e corretoras de investimento. Uma senha comprometida permite que pessoas acessem sua conta, mas um número de telefone comprometido permite acesso às suas contas e muito mais. Isso é bem pior.

Estão ligados ao seu CPF no Brasil. Para brasileiros, números de telefone são uma conexão direta à identidade física e rastreável de alguém. Não são anônimos.

São permanentes como seu CPF, mas não como seus emails. Não é fácil trocar de número de telefone. Pessoas trocam emails, mas podem ser identificadas pelos seus números de telefone daqui a dez ou mais anos.

Números de telefone são a ponte entre as principais plataformas. São uma das informações mais utilizadas por corretores de dados para cruzar informações. Você talvez não saiba, mas adicionar um telefone pode virar parte de uma ferramenta de cruzamento de dados.

A Pergunta Que Vem Antes de Codificar

A equipe deve responder uma questão de decisão de arquitetura e produto sobre a implementação de um fluxo de verificação por telefone. Essa questão deve ser resolvida antes de qualquer linha de código.

A questão é: “Após a verificação, ainda queremos manter o número de telefone?”

A maioria dos aplicativos opta por não responder a essa questão, e mantém o número, independentemente de precisar ou não dele.

Alguns casos de uso:

Sim, você precisará do número se planeja usar sua implementação de SMS como login na 2FA. Nesse caso, será necessário o número de SMS para enviar a mensagem, e ele deve ser capturado com cuidado.

Sim, o aplicativo precisará do número de SMS do usuário se planeja enviar notificações ou alertas via SMS. Novamente, o mesmo cuidado na coleta e uso do número.

Se o objetivo da verificação é apenas confirmar que o usuário tem acesso a um dispositivo real, provavelmente não é necessário manter o número. Um token ou hash da verificação será suficiente.

Provavelmente, você não precisa guardar o número se o objetivo é evitar múltiplos cadastros com o mesmo número. Um hash criptográfico do número será suficiente e atenderá ao requisito de verificação.

Princípios de Implementação Responsável

Princípio 1: Minimização de Dados

Esse princípio também está na LGPD (Artigo 6º, III). É uma boa prática minimizar a coleta de dados, mesmo quando a lei não exige.

Na prática: armazenar um número apenas para enviar um SMS depois é desnecessário. Se o número precisar ser verificado, pode-se usar um hash para verificar se um número já foi utilizado. Se for necessário usar o número para completar uma verificação em duas etapas, então ele pode ser criptografado.

Como você nunca armazenou o número, ele não pode vazar. Também não precisa procurar uma resposta para perguntas sobre possíveis vazamentos.

Princípio 2: Os Dados Mais Seguros São Dados Inexistentes

Na segurança de dados, os dados mais seguros são aqueles que você não possui.

Cada ponto de dado representa um risco e uma obrigação. Números de telefone são os dados de maior risco.

Ao optar por não armazenar o número ou apenas armazenar seu hash, simplifica-se o sistema e elimina-se risco de ataque completo.

Princípio 3: Separação entre Prova e Dados

Esse é o princípio mais poderoso, mas o menos utilizado.

Quando um usuário verifica seu número, tudo que você precisa é de uma prova de que a verificação ocorreu, e não precisa armazenar o número.

Com duas informações distintas, separar a gestão delas proporciona mais controle.

Pense assim: após verificar o telefone, você poderia enviar esse número a um serviço de mensagens que dele precisa para enviar mensagens. Você enviaria o número ao serviço de mensagens, enquanto o restante do sistema recebaria um token dizendo: “Este usuário verificou seu telefone,” e esse token não conteria o número. O número não precisa estar fora do serviço de mensagens.

Separar o número dessa forma também significa que uma vulnerabilidade no sistema principal não vazaria os números de telefone. Você poderia até deletar o número e isso não afetaria a verificação do usuário. Desenvolvedores que não precisam do acesso ao número nunca precisariam vê-lo.

A criptografia é uma exigência ao armazenar

Se você chegar à conclusão de que não pode evitar armazenar o número de telefone do usuário, então deve saber que não pode permitir que números de telefone sejam armazenados sem criptografia após 2025.

O que isso significa na prática, independentemente da linguagem ou pilha de tecnologia que você estiver usando?

Você deve implementar criptografia simétrica autenticada. AES-256-GCM é o padrão atual para criptografia. Não use modos de criptografia mais antigos que não forneçam criptografia autenticada, pois eles estão vulneráveis a múltiplas ameaças.
A chave de criptografia deve ser gerenciada externamente. Se a chave estiver no mesmo sistema que os dados, muitas vezes a criptografia não fornece tanta proteção quanto parece. AWS, GCP e HashiCorp Vault são soluções padrão.
Planeje a rotação de chaves desde o início — a rotação de chaves é difícil de implementar posteriormente. Planejar antecipadamente é muito mais fácil. Para isso, mantém-se um registro de qual chave foi usada para criptografar um registro.
Crie um hash para buscas e deduplication — não é possível pesquisar um campo criptografado. Para contornar isso, é armazenado um hash que ainda é secreto, mas é determinístico, e permite verificar se um registro existe.

Princípio 5: Seus Logs Nunca Devem Conter Números de Telefone

Este é um dos erros mais comuns e ainda subestima frequentemente o risco.

Os logs de aplicativos são alguns dos dados mais facilmente acessíveis no sistema. Eles estão disponíveis para toda a equipe de desenvolvimento, enviados para serviços externos de monitoramento, possuem uma política de retenção de dados prolongada e raramente são criptografados.

Um único console.log ou print descuidado com um número de telefone pode permitir que esse número apareça em:

Logs de aplicativo acessíveis a todos os desenvolvedores
Ferramentas de monitoramento como Datadog, New Relic e Splunk
Logs de erros enviados ao Sentry, Bugsnag, e similares
Logs em aplicações que são menos seguras que o banco de dados de produção

O número de telefone nunca deve estar nos logs. Se precisar rastrear um caso específico, registre os últimos quatro dígitos ou um identificador aleatório do caso.

Princípio 6: Limitação de Taxa Protege a Privacidade Além do Custo do SMS

É comum justificar a limitação de taxa de verificação por SMS pelo custo da mensagem. No entanto, também é uma forma de proteger a privacidade.

Sem limitação de taxa, atacantes podem fazer várias ações maliciosas com seu endpoint. Eles podem:

Enumeração de números — verificar quais números estão no sistema comparando as diferenças de respostas (como, se o número está registrado ou não).
Abuso de SMS — confirmar se os atacantes podem enviar mensagens para um número e causar uma situação de assédio.
Análise de comportamento — em sistemas que possuem mensagens diferentes para usuários ativos ou não, podem analisar o comportamento e descobrir quando os usuários estão ativos.

Boa limitação de taxa aplica duas dimensões: por IP e por número de telefone. A primeira aplica-se ao atacante e a segunda protege o usuário de muitas tentativas. A segunda dimensão geralmente é negligenciada.

Princípio 7: Respostas de Erro Não Devem Confirmar Existência

Este princípio é para proteção contra enumeração.

Se houver respostas diferentes para os códigos como "número não registrado", "número já verificado" ou "número localizado", seu endpoint está vazando informações. Atacantes podem automatizar sistemas para verificar números e não precisam de técnicas sofisticadas. A única forma de responder ao usuário é: "Se este número for válido, você receberá um código em breve", e tudo mais deve ser processado em segundo plano.

O Ciclo de Vida do Número: Registro até Descarte

Uma implementação deve definir o que significa o ciclo completo do número de telefone no sistema.

Aqui está a abordagem passo a passo que adotamos para lidar com informações sensíveis.

Coleta: Geraremos informações apenas quando tivermos uma razão específica para isso, e o sujeito tiver fornecido consentimento informado. O sujeito deve saber para que sua contribuição será usada.
Verificação: A informação existsirá apenas no cache de sessão temporária. Ela nunca será mantida em cache permanente desnecessariamente.
Pós-verificação: Tomaremos uma decisão informada sobre o que armazenar. Armazenaremos a informação em formato de hash para deduplicação. Se precisarmos relacionar essa informação para comunicação futura, encryptaremos a informação. Nada será armazenado em texto simples.
Uso ativo: A informação só será acessada pelo serviço que precisa dela por uma razão específica e particular. A informação não estará acessível como dados gerais do usuário para toda a aplicação.
Inatividade: Teremos uma política de retenção definida. Após um número predeterminado de meses sem uso relevante, a informação será removida ou anonimizada automaticamente.
Exclusão sob solicitação: O sujeito tem o direito (LGPD Art. 18, IV) de solicitar a remoção de suas informações. O processo será implementado e não ficará como uma promessa vazia.

O que isso tem a ver com Números Virtuais?

Se você está trabalhando na integração de verificação por SMS — que todo desenvolvedor precisa fazer em algum momento — há uma prática que incentiva o uso de um número virtual dedicado para ambientes de teste e homologação.

Por que você deve se preocupar?

Quando você usa seu número pessoal para testar o fluxo de verificação por SMS do seu produto, está adicionando seus dados pessoais reais a um ambiente de teste que provavelmente possui menos segurança rigorosa e registros de auditoria do que o ambiente de produção. Isso vai totalmente contra tudo que discutimos até agora.

Uma olhada no pacote random-sms-number disponível no npm nos dá uma maneira limpa de lidar com o problema apresentado anteriormente.

Esse número é temporário, útil apenas para o teste, e nem pertencerá ao membro da equipe nem ajudará o membro. Se o projeto for considerado concluído, esse número pode facilmente ser descartado junto com o ambiente.

Aqueles que trabalham no Brasil podem optar pelo NumeroVirtual.net, que é adequado para fornecer números virtuais de alta qualidade e compatíveis para SMS, o que elimina a necessidade de pedir aos membros da equipe que forneçam seu número de celular para o trabalho.

Isso demonstra respeito pelos números de celular privados das pessoas, e o princípio por trás disso é o mesmo respeito pelos dados pessoais.

Implementando os Conceitos Acima

Você pode aplicar os princípios descritos nas seções anteriores com qualquer linguagem de programação com a qual trabalhe. Go, Python, Ruby, PHP, Java, Rust. Além das bibliotecas disponíveis, as opções de design permanecerão as mesmas.

O que Saber Antes de Adicionar Verificação de Número de Telefone

Reúna sua equipe e responda às seguintes perguntas.

Por que precisamos de um número verificado? Para que propósito? Quanto tempo precisamos dele?
Se decidirmos salvá-lo, como planejamos mantê-lo seguro? Onde colocaremos a trava de segurança? Como evitaremos que a trava de segurança seja utilizada em excesso?
Se estamos salvando números, tudo bem que eles nunca apareçam nos logs? Checamos tudo para ver se eles são registrados?
Quando planejamos eliminar os números dos usuários? Como planejamos fazer isso? Realmente vamos remover os números se o usuário pedir?
Quem planejamos deixar usar os números para testar isso? Existe um número virtual especial para isso ou planejamos usar números pessoais?

Você responderá a essas perguntas antes de adicionar qualquer código de verificação de telefone, e seu código será melhor por isso, independentemente do estilo de programação que usar ou do tamanho do projeto.

Respeitando a Privacidade dos Usuários

Respeitar a privacidade dos usuários não é algo que você deve planejar fazer depois. É algo que você deve decidir durante as fases de planejamento de um projeto.

Os números de telefone que você decidir salvar não desaparecerão. As pessoas migrarão os números salvos. Backups precisarão ser feitos. Normas mudarão, e números antigos se tornarão novos novamente.

Cuidar dos dados dos usuários faz parte de uma construção de produto responsável. Descobrimos que usuários e reguladores gostariam de ver isso feito em todos os produtos criados no Brasil e além. Já passou da hora de essa prática ser adotada em todas as línguas e todos os produtos.

Qual desses princípios você acha que os desenvolvedores mais ignoram no mundo real? Coloque nos comentários. Esse é o tipo de crítica construtiva que une a comunidade de desenvolvedores.

Privacidade por Design: Por Que Seu App Não Deveria Pedir Número de Telefone (E O Que Fazer Quando Precisa)

Kairox — Sat, 25 Jul 2026 10:54:46 +0000

A pergunta que poucos devs fazem antes de adicionar aquele campo de telefone no formulário

Deixa eu te fazer uma pergunta direta.

Na última vez que você adicionou um campo de número de telefone num formulário de cadastro — você parou para perguntar se realmente precisava dele?

Ou foi automático? O design pedia, o PM pediu, "todo mundo pede número de telefone", e lá foi o campo.

Esse é o ponto de partida que eu quero questionar nesse artigo. Não porque número de telefone seja sempre desnecessário — às vezes é genuinamente importante. Mas porque a maioria dos apps pede por hábito, não por necessidade. E essa diferença tem consequências reais para seus usuários e, dependendo do contexto, para a sua empresa.

O Princípio Que Muda Como Você Pensa Sobre Isso

Privacidade por design não é uma regulamentação nem um checklist. É uma filosofia de desenvolvimento que diz: considere privacidade desde o início, não como camada adicionada depois.

Um dos princípios centrais é minimização de dados — colete apenas o que você genuinamente precisa para entregar o serviço. Não o que pode ser útil no futuro. Não o que seria interessante para análise. O que você precisa agora, para o que o usuário veio fazer.

Aplicado ao número de telefone, a pergunta fica simples: para que exatamente você vai usar esse número?

Se a resposta for vaga — "para contato", "para segurança", "todo mundo pede" — você provavelmente não precisa dele.

Os Casos Onde Você Realmente Precisa vs. Os Que Pensa Que Precisa

Vamos ser honestos sobre quando o número de telefone é necessário de verdade.

Casos onde faz sentido:

✓ Autenticação de dois fatores por SMS (quando não há alternativa melhor)
✓ Serviços onde o número é o produto (apps de chamada, WhatsApp clones)
✓ Recuperação de conta quando email não é suficiente por regulamentação
✓ Verificação de identidade exigida por compliance (fintech, saúde)
✓ Notificações urgentes onde email tem latência inaceitável

Casos onde você provavelmente não precisa:

✗ "Para entrar em contato se necessário" — email resolve
✗ "Para segurança adicional" — app autenticador é mais seguro
✗ "Para personalização" — não precisa de número para isso
✗ "Para verificar que é uma pessoa real" — existem outras formas
✗ "Porque o template de cadastro já tinha o campo" — sério?

A diferença entre essas duas listas determina se você está coletando dado necessário ou dado desnecessário com consequências desnecessárias.

O Que Acontece Com o Número Depois Que Você Coleta

Aqui está a parte que muitos devs não pensam porque não é sua responsabilidade direta — mas deveria ser parte da conversa quando o campo é adicionado.

Quando um usuário fornece o número de telefone para o seu app:

Ele vai para o banco de dados. Óbvio. Mas com quais controles de acesso? Quem na sua empresa consegue consultar números de usuários? Está criptografado em repouso?
Ele provavelmente vai para analytics. Muitas stacks de analytics coletam propriedades de usuário automaticamente. Você verificou se o número não está sendo enviado para ferramentas de terceiros sem mascaramento?
Ele pode ir para serviços de marketing. Se existe integração com CRM ou ferramentas de email marketing, o número pode estar sendo sincronizado para sistemas com políticas de privacidade diferentes das suas.
Ele vai ficar lá por tempo indefinido — a menos que você tenha implementado explicitamente uma política de retenção e um mecanismo de exclusão.

python

O que muitos sistemas fazem com dados de telefone:

class UserProfile(Model):
phone_number = CharField(max_length=20)
# Sem criptografia
# Sem política de retenção
# Sem log de quem acessa
# Sem mecanismo de exclusão automatizada
# Sincronizado automaticamente com o CRM
# Incluído nos backups que ficam por 7 anos

Quando você coleta um número de telefone, você está assumindo a responsabilidade por todos esses pontos. Se a pergunta "precisamos mesmo desse número?" não foi feita antes, esses problemas aparecem depois — geralmente na forma de um incidente de segurança ou uma pergunta difícil de auditoria.

Alternativas Técnicas Para Casos Comuns
Em vez de SMS para 2FA → Use TOTP

App autenticador (Google Authenticator, Authy, qualquer implementação TOTP) é tecnicamente superior ao SMS para autenticação de dois fatores em praticamente todos os aspectos relevantes:

python
import pyotp

Gerar secret para o usuário

secret = pyotp.random_base32()

Gerar URI para QR code (usuário escaneia no app autenticador)

totp = pyotp.TOTP(secret)
uri = totp.provisioning_uri(
name=user.email,
issuer_name="SeuApp"
)

Verificar código que o usuário digitou

def verify_totp(user_secret: str, code: str) -> bool:
totp = pyotp.TOTP(user_secret)
return totp.verify(code, valid_window=1)

Sem SMS, sem número de telefone coletado, sem vulnerabilidade SS7, sem risco de SIM swap. Mais seguro para o usuário, menos responsabilidade para você.

Em vez de SMS para verificação de cadastro → Use Email + Magic Link

Para verificar que o usuário tem acesso a um contato válido, email com magic link é suficiente para a maioria dos casos:

python
import secrets
from datetime import datetime, timedelta

def generate_magic_link(user_email: str) -> str:
token = secrets.token_urlsafe(32)
expiry = datetime.utcnow() + timedelta(minutes=15)

# Armazena token hasheado, não em plaintext
store_token(
    email=user_email,
    token_hash=hash_token(token),
    expires_at=expiry
)

return f"https://seuapp.com/verify?token={token}"

Envia por email, sem precisar de número de telefone

send_email(
to=user_email,
subject="Confirme seu cadastro",
body=f"Clique aqui para confirmar: {generate_magic_link(user_email)}"
)

Sem número de telefone coletado. Funciona para a grande maioria dos casos de verificação de cadastro.

Em vez de SMS para notificações → Use Push Notifications

Se você tem um app mobile e precisa notificar usuários de forma rápida, push notifications via FCM/APNs são mais confiáveis, mais rápidas, e não requerem número de telefone:

javascript
// Firebase Cloud Messaging — sem número de telefone
const message = {
notification: {
title: 'Atualização importante',
body: 'Sua solicitação foi processada'
},
token: user.fcmToken // Token do dispositivo, não número de telefone
};

await admin.messaging().send(message);
Quando Você Genuinamente Precisa Do Número: Faça Do Jeito Certo

Ok, digamos que você passou pela análise e realmente precisa do número. Talvez seja uma fintech com requisitos de KYC. Talvez seja um serviço de comunicação. Seja qual for o motivo legítimo — aqui está como implementar com responsabilidade.

Seja explícito sobre por que você precisa:

html

Usaremos este número apenas para enviar seu código de verificação. Não usamos para marketing e não compartilhamos com terceiros.

Armazene com criptografia:

python
from cryptography.fernet import Fernet

Nunca armazene número de telefone em plaintext em produção

class UserProfile(Model):
_phone_encrypted = BinaryField()

@property
def phone_number(self) -> str:
    return decrypt(self._phone_encrypted)

@phone_number.setter
def phone_number(self, value: str):
    # Normaliza para E.164 antes de criptografar
    normalized = normalize_phone(value)
    self._phone_encrypted = encrypt(normalized)

Implemente exclusão real:

python
def delete_user_phone(user_id: int) -> None:
user = User.get(user_id)

# Remove do banco principal
user.phone_number = None
user.save()

# Remove de sistemas conectados
crm.remove_contact(user.email)
analytics.delete_user_property(user.id, 'phone')

# Log para auditoria (sem o número em si)
audit_log.record(
    action='phone_deleted',
    user_id=user_id,
    timestamp=datetime.utcnow()
)

Para o caso de uso onde número virtual faz sentido no seu produto:

Se você está construindo um serviço onde usuários precisam de um número para verificação mas você quer minimizar a coleta de dados pessoais, considere integrar com provedores de números virtuais como parte da arquitetura. Em vez de pedir o número pessoal do usuário, você provisiona um número virtual para aquela sessão ou propósito específico.

Para entender como isso funciona na prática e quais casos de uso são suportados, o NumeroVirtual é um provedor com foco em verificação por SMS e privacidade que vale explorar como referência de como esse tipo de serviço pode ser estruturado.

A Conversa Que Você Deveria Ter Com o PM

Se você está lendo isso como dev e pensando "mas o PM pediu o campo de telefone", aqui está o framework para a conversa:

PM: "Precisa ter campo de telefone no cadastro."

Dev: "Para que exatamente vamos usar esse número?"

PM: "Para contato se necessário / segurança / verificação."

Dev: "Email não resolve o contato?
App autenticador não é mais seguro para verificação?
Se for só para ter, o custo de coletar e proteger
esse dado é maior do que o benefício?"

Não é uma conversa adversarial. É o dev trazendo perspectiva de implementação e compliance que o PM pode não ter considerado. Na maioria das vezes, quando a questão é colocada dessa forma, a resposta é que email resolve, ou que o TOTP é mais seguro mesmo, ou que o campo era padrão do template e ninguém tinha pensado se era necessário.

Essa conversa é mais fácil antes de implementar do que depois de ter coletado dados de milhares de usuários que agora precisam ser gerenciados, protegidos, e potencialmente excluídos.

LGPD e o Princípio da Necessidade

No contexto brasileiro, a LGPD tem um artigo específico que é diretamente relevante aqui: o princípio da necessidade — limitação do tratamento ao mínimo necessário para a realização das finalidades de tratamento.

Na prática, isso significa que se você coleta um número de telefone e não consegue articular claramente a finalidade específica e necessária para aquela coleta, você pode estar em desacordo com a lei — independente de ter um banner de cookies bonito ou uma política de privacidade extensa.

O teste simples: você consegue responder "por que precisamos desse número" com uma finalidade específica, não com "pode ser útil"?

Se não, você não deveria estar coletando.

TL;DR Para Copiar e Mandar Para o Time
Antes de adicionar campo de telefone:

Por que exatamente precisamos desse número?
Se a resposta for vaga → não adicione
Email não resolve?
Para contato e verificação de cadastro → geralmente resolve
TOTP não é mais seguro para 2FA?
Para autenticação → quase sempre sim
Se precisar coletar:
→ Seja explícito sobre o uso na UI
→ Armazene criptografado
→ Implemente exclusão real
→ Documente a finalidade para compliance LGPD
Princípio geral:
Dado que você não coleta não pode vazar,
não pode ser mal usado, e não vira problema de compliance.

Você já teve essa conversa sobre coleta de número de telefone no seu time? Ou passou por algum momento onde percebeu que estava coletando dado desnecessário? Conta nos comentários — esse tipo de experiência real ajuda muito mais do que qualquer doc de boas práticas.