Nos últimos testes de um chat de agendamento pensado para clínicas e consultórios menores, o fluxo era simples: a pessoa conversa no site, e quando quer confirmar ou ver o próprio horário marcado, digita o número de WhatsApp dela. O chat usa esse número para achar a consulta certa e mostrar os dados. Funcionou em todo teste interno, até uma revisão antes de qualquer cliente real usar aquilo perguntar uma coisa simples: o que impede alguém de digitar o número de outra pessoa e ver a consulta dela?

A resposta, olhando o código com essa pergunta em mente, era nada. O chat conferia se existia uma consulta com aquele número, não se quem digitou era o dono daquele número. Bastava digitar um número que não fosse seu para ver nome, horário e motivo da consulta de outra pessoa, sem senha, sem login, sem nenhuma barreira além de escrever e apertar enviar.

Por que confiar no que a pessoa digita é o erro de autorização mais repetido

A OWASP, organização sem fins lucrativos que mantém guias de segurança usados no mundo inteiro, publica desde 2019 um ranking específico para vulnerabilidade de API, montado a partir do que profissionais de segurança mais encontram em auditoria real. Na edição de 2023 o primeiro lugar desse ranking, chamado API1:2023, é a Broken Object Level Authorization: uma rota que aceita um identificador vindo de quem pede, um número de telefone, um ID de pedido, um CPF, e devolve o registro correspondente sem checar se quem pediu é o dono daquele identificador. O ponto que o próprio guia destaca é direto: explorar esse furo não exige quebrar senha nem login. A pessoa pode estar completamente autenticada, ou nem precisar estar, como no caso do chat. O problema nunca é entrar sem permissão. É pedir um dado que não é seu e receber de volta do mesmo jeito que receberia o próprio.

Esse furo já aconteceu de verdade, e ficou oito meses no ar

Para não ficar só na teoria: em agosto de 2017 um pesquisador avisou em privado a rede americana de padarias Panera Bread que o site dela expunha nome, endereço, data de nascimento e os quatro últimos dígitos do cartão salvo de qualquer cliente que já tivesse feito pedido online. Bastava trocar um número sequencial na própria URL do pedido, sem senha nenhuma para ver o registro de outra pessoa. Brian Krebs, jornalista que cobre segurança digital há mais de uma década, publicou o caso em abril de 2018 e contou que o furo continuava no ar quase oito meses depois daquele primeiro aviso. Sobre o tamanho, os números nunca bateram: a Panera falou em menos de dez mil clientes afetados, e o pesquisador que achou o furo, acompanhando a reportagem de Krebs, apontava potencialmente milhões de registros expostos. Essa divergência nunca foi resolvida publicamente, mas o mecanismo do erro é idêntico ao do chat testado aqui: nenhuma verificação de que o identificador pedido pertencia a quem pedia.

O que mudou no chat, e por quê

A correção não foi exigir senha ou mandar código de confirmação por SMS a cada consulta. Isso resolveria o furo e criaria dois problemas novos: mais um passo para quem só quer confirmar um horário, e custo de mensagem para cada código enviado. A mudança foi outra: o chat deixou de aceitar número digitado como prova de identidade. A pessoa recebe um link e abre esse link no próprio celular, no WhatsApp que já está logado ali. O número de quem está perguntando passa a vir do aparelho, não do que foi escrito numa caixa de texto que aceita qualquer sequência de onze dígitos.

É a mesma lição que telemetria real do setor de segurança de API reforça. A Salt Security, empresa que vende proteção de API e cruza pesquisa com mais de duzentos profissionais de segurança e dados anonimizados dos próprios clientes, publicou no relatório do primeiro trimestre de 2025 que 95 por cento dos ataques a API observados nos doze meses anteriores vieram de fontes já autenticadas. Ou seja, de alguém que já tinha acesso legítimo e só pediu um dado que não devia receber. Checar senha não resolve esse tipo de furo, porque quem explora não está tentando entrar. Já entrou. Está só pedindo o que não é dele.

O que fica, mesmo sem código

Campo que a pessoa digita nunca é prova de quem ela é, por mais que pareça. Um número de telefone, um CPF, um ID de pedido: tudo isso é dado que qualquer um pode escrever numa caixa de texto, inclusive o dado de outra pessoa. Prova de identidade vem de algo que só o dono controla: o aparelho que recebe o link, a sessão que já está logada, o canal que a própria empresa abriu para aquela pessoa específica. Antes de qualquer chat, formulário ou automação devolver um dado a partir de um identificador, a pergunta vale sempre a mesma coisa: o que, exatamente, prova que quem está pedindo é o dono daquilo, e não só alguém que acertou o número certo.