Segurança de APIs: as 5 falhas que expõem os dados da sua empresa (e como corrigir)

Firewall configurado, HTTPS ativo, site atualizado. Ainda assim, os dados dos seus clientes podem estar a uma requisição de distância de qualquer pessoa na internet. O motivo quase sempre é o mesmo: as APIs. Neste artigo, mostramos onde estão as falhas que mais expõem empresas hoje, como elas são corrigidas no código e na infraestrutura e o que avaliar antes que o problema vire incidente.

O ponto cego da maioria das empresas

Toda integração moderna passa por uma API: o app que consulta pedidos, o e-commerce que fala com o ERP, o CRM que recebe mensagens do WhatsApp, o parceiro que puxa o seu catálogo. Segundo o Cloudflare Radar, 58% do tráfego HTTP dinâmico da internet já é tráfego de API.

O problema é que a segurança não acompanhou esse crescimento. A Gartner previa que, até 2025, menos da metade das APIs corporativas estaria sob gestão. Na prática, muitas empresas não sabem quantas APIs têm em produção, quem as consome e quais dados elas devolvem.

É exatamente esse espaço que os atacantes exploram. O site principal costuma receber firewall, testes e atenção. A API foi criada para uma integração com prazo apertado e nunca mais foi revisada. Foi por APIs que vieram à tona casos como a coleta de dados de cerca de 700 milhões de perfis do LinkedIn e as falhas exploradas durante anos na T-Mobile.

O que está em jogo para o negócio

Segurança de API não é um tema só do time técnico. Uma falha aqui tem custo direto:

• LGPD: um vazamento de dados pessoais pode gerar sanções da ANPD de até 2% do faturamento, limitadas a R$ 50 milhões por infração, além da obrigação de comunicar o incidente aos titulares.
• Operação parada: uma API sem limite de uso pode ser derrubada por excesso de requisições, e com ela caem o app, o checkout e as integrações.
• Concorrência: APIs abertas demais permitem que terceiros copiem catálogo, preços e estoque de forma automatizada.
• Confiança: cliente que recebe o aviso de que seus dados vazaram dificilmente compra de novo.

Por que proteger o site não basta

Ferramentas pensadas para sites olham para formulários, scripts e navegação. A API funciona de outro jeito: recebe e devolve dados puros (JSON), é consumida por sistemas e não por pessoas e conversa diretamente com o banco de dados. Uma chamada maliciosa a uma API costuma ser idêntica a uma chamada legítima. A diferença está no contexto: quem está pedindo, o quê e com que frequência.

Por isso a regra fundamental é: toda operação de API precisa validar a identidade e a permissão de quem chama, a cada requisição. Estar autenticado não significa estar autorizado.

As 5 falhas que mais expõem empresas

A referência do mercado para o tema é o OWASP API Security Top 10, a lista das vulnerabilidades de API mais exploradas. As cinco abaixo concentram a maior parte dos incidentes e são as primeiras que avaliamos em um diagnóstico.

1. Acesso a dados de outros usuários (OWASP API1: BOLA)

É a falha número um do ranking. A API confirma que o usuário fez login, mas não confirma se o registro pedido pertence a ele:

GET /api/pedidos/1042   → 200 OK  (pedido do usuário)
GET /api/pedidos/1043   → 200 OK  (pedido de outro cliente)

Com um script simples, alguém percorre todos os IDs e baixa a base inteira. A correção fica no código: toda consulta filtra pelo dono do recurso, que vem do token, nunca do que o cliente envia.

[Authorize]
[HttpGet("{id:int}")]
public async Task<IActionResult> Obter(int id)
{
    var clienteId = User.FindFirstValue(ClaimTypes.NameIdentifier);

    var pedido = await _db.Pedidos
        .Where(p => p.Id == id && p.ClienteId == clienteId)
        .Select(p => new PedidoDto(p.Id, p.Status, p.Total))
        .FirstOrDefaultAsync();

    // 404 em vez de 403: não confirma que o pedido existe
    return pedido is null ? NotFound() : Ok(pedido);
}

2. Autenticação frágil (OWASP API2)

Tokens que nunca expiram, chaves de API fixas no código do app, endpoints de login sem proteção contra tentativa e erro. Basta um token vazado para alguém agir em nome do cliente.

Como resolvemos: tokens JWT ou OAuth 2.0 de curta duração, com assinatura, emissor e validade conferidos em toda requisição; mTLS para integrações entre servidores; e bloqueio progressivo em login e recuperação de senha.

3. Exposição excessiva de dados (OWASP API3)

A tela mostra o nome do cliente, mas a resposta da API devolve CPF, telefone, endereço e às vezes até o hash da senha. Qualquer pessoa que abra as ferramentas do navegador vê tudo.

Como resolvemos: a API nunca devolve a entidade do banco diretamente. Cada endpoint tem um DTO com apenas os campos necessários, como o PedidoDto do exemplo acima. Na borda, a detecção de dados sensíveis alerta quando CPF, cartão ou credenciais aparecem em uma resposta.

4. Consumo sem limite (OWASP API4)

Sem limite de requisições, a API fica aberta a força bruta em senhas, raspagem de catálogo e ataques de negação de serviço. Uma listagem sem paginação permite baixar milhões de registros em uma chamada.

Como resolvemos: rate limiting no código e na borda, com limites calibrados pelo tráfego real de cada endpoint, e paginação obrigatória. Os frameworks modernos já trazem isso pronto, seja em .NET, Node.js, Java, PHP ou Python. Um exemplo em ASP.NET Core:

builder.Services.AddRateLimiter(o =>
{
    o.RejectionStatusCode = StatusCodes.Status429TooManyRequests;
    o.AddFixedWindowLimiter("api", l =>
    {
        l.PermitLimit = 100;                // 100 requisições
        l.Window = TimeSpan.FromMinutes(1); // por minuto
    });
});

app.MapControllers().RequireRateLimiting("api");

5. APIs esquecidas (OWASP API9)

A /api/v1 que deveria ter sido desligada, o endpoint de teste que foi para produção, a integração de um fornecedor antigo. São as chamadas shadow APIs: não aparecem em nenhuma documentação, não recebem correções e são as preferidas de quem procura uma porta aberta.

Como resolvemos: inventário contínuo a partir do tráfego real, documentação OpenAPI gerada pelo próprio código, versões antigas com data de desligamento e um responsável definido para cada API.

Segurança em camadas: código, borda e monitoramento

Nenhuma ferramenta isolada resolve o problema. A proteção que funciona combina três camadas:

1. No código: autorização por recurso, DTOs, validação de entrada e rate limiting. É onde se elimina a causa da falha.
2. Na borda: um gateway de API com WAF, como o da Cloudflare, posicionado na frente do servidor. Ele valida tokens, aplica limites, bloqueia ataques conhecidos e descobre endpoints não documentados antes que o tráfego chegue à sua infraestrutura.
3. No monitoramento: logs de auditoria de quem acessou o quê e quando, alertas de comportamento anormal e registros que atendem às exigências da LGPD.

Abordagem	Indicada para	Limitação
Observabilidade de APIs	Entender o tráfego em homologação	Identifica, mas não bloqueia
Gestão do ciclo de vida	Setores regulados e APIs legadas	Forte em governança, fraca em proteção ativa
Proteção de aplicações web e APIs (WAAP)	APIs em produção	Precisa ser combinada com correções no código

Sua empresa está exposta? Responda com sinceridade

• Você tem uma lista atualizada de todas as APIs em produção, inclusive as de fornecedores?
• Toda consulta confere se o registro pertence ao usuário do token?
• Os tokens expiram e são validados a cada requisição?
• As respostas devolvem só os campos que a aplicação usa?
• Existe limite de requisições por endpoint e paginação nas listagens?
• Há logs que mostram quem acessou quais dados pessoais?
• Existe uma camada de proteção (WAF ou gateway) na frente das APIs?

Se a resposta foi “não” ou “não sei” para qualquer item, a sua API provavelmente tem uma porta aberta, e é melhor que você a encontre antes de outra pessoa.

Como a CPW protege as suas APIs

Há mais de 10 anos projetamos, desenvolvemos e mantemos APIs na tecnologia que faz mais sentido para cada negócio, e segurança faz parte do projeto desde a primeira linha de código, não de um ajuste no fim. Para empresas que já têm APIs em produção, seja qual for a linguagem ou a nuvem, o trabalho segue três etapas:

1. Diagnóstico: inventário das APIs e testes baseados no OWASP API Security Top 10, com um relatório de riscos priorizado por impacto no negócio.
2. Correção: ajustes no código, como autorização por recurso, DTOs, tokens e rate limiting, sem parar a operação.
3. Proteção contínua: configuração da camada de borda, monitoramento e hospedagem gerenciada com HTTPS e CDN.

Quer saber se as APIs da sua empresa estão expostas? Fale com a gente pelo WhatsApp e agende um diagnóstico.

Dados do Cloudflare Radar e da Gartner citados a partir do eBook “Guia sobre segurança de APIs para CISOs”, da Cloudflare (2023). Classificação de vulnerabilidades: OWASP API Security Top 10 (2023).