Segurança de API: a superfície que cresce mais rápido e recebe menos atenção dedicada

Praticamente toda funcionalidade nova de produto hoje nasce como uma API antes de virar tela. Aplicativo mobile, integração com parceiro, microsserviço interno conversando com outro — tudo isso é tráfego de API, crescendo mais rápido do que qualquer outra superfície de exposição da empresa. E, na prática, é a que recebe menos atenção de segurança dedicada, proporcional ao volume que representa.

Parte do motivo é histórico: segurança de aplicação amadureceu tratando página web como unidade de análise. API não é página — é contrato de dado entre sistemas, e os erros que mais custam caro nela raramente são os mesmos que um firewall de aplicação web foi desenhado pra pegar.

Por que WAF tradicional não é suficiente sozinho

Um firewall de aplicação web foi construído pra reconhecer padrão de ataque conhecido — injeção de SQL, script malicioso, assinatura de exploit catalogada. A maioria dos incidentes de API graves não usa nada disso: usa uma chamada perfeitamente bem formada, autenticada com credencial válida, pedindo um recurso que o sistema não deveria entregar pra aquele usuário específico.

Isso é falha de lógica de autorização, não de padrão malicioso reconhecível — e é exatamente o tipo de coisa que ferramenta baseada em assinatura de ataque simplesmente não enxerga, porque a chamada, isoladamente, parece legítima.

As falhas que mais aparecem na prática

Duas categorias concentram a maior parte do risco real: autorização quebrada no nível do objeto — quando trocar um número de ID na URL da chamada de API expõe dado de outro usuário, porque o sistema verifica autenticação mas não verifica se aquele usuário autenticado deveria ver aquele registro específico — e exposição excessiva de dado, quando a API retorna o objeto inteiro do banco e deixa o filtro do que mostrar por conta do aplicativo cliente, que nem sempre filtra direito.

Nenhuma das duas exige exploit sofisticado. Exigem só alguém testando sistematicamente o que acontece quando se muda um parâmetro — o que torna essas falhas ao mesmo tempo comuns e baratas de corrigir, uma vez encontradas.

Zombie API: a versão antiga que ninguém desligou

Toda empresa que já passou por mais de uma versão de API tem endpoints antigos ainda respondendo, sem documentação atualizada, muitas vezes sem o mesmo nível de controle da versão atual. Ninguém desliga de propósito — simplesmente não há processo formal de aposentar endpoint, então ele continua ativo, esquecido, até alguém descobrir que ainda funciona.

É a mesma dinâmica de descoberta que já apareceu aqui esta semana com SaaS não homologado — superfície que cresce por acúmulo, sem inventário confiável, até que alguém de fora encontra antes da própria empresa.

Descoberta de API antes de qualquer controle

A pergunta que deveria abrir qualquer iniciativa de segurança de API não é "qual ferramenta de proteção comprar" — é "quantos endpoints realmente existem, documentados ou não, e o que cada um expõe". Ferramentas de descoberta de API hoje conseguem mapear tráfego real de produção e revelar endpoints que nunca entraram em nenhum inventário formal — informação que normalmente muda completamente a priorização do que proteger primeiro.

Esse mapeamento é pré-requisito pra qualquer validação séria depois — inclusive validação ofensiva contínua, que só testa o que sabe que existe.

Onde isso pesa mais

Setores com API como superfície crítica de negócio — serviços financeiros, qualquer empresa com app mobile como canal principal — sentem esse risco primeiro e de forma mais direta, porque a API ali não é infraestrutura de suporte, é o próprio produto. Mas nenhuma empresa moderna está isenta: se existe aplicativo, parceiro integrado ou microsserviço, existe API crescendo fora do radar.

Cada endpoint é uma porta, não um detalhe técnico

Tratar API como preocupação de engenharia, separada da conversa de segurança, é o erro mais caro nessa categoria. A UNIQ ajuda clientes a construir a camada de descoberta e controle de API dentro da arquitetura de Exposure & AppSec, começando sempre pelo inventário — antes de decidir qual proteção faz sentido pra cada endpoint.