Seguranca APIs: 11 erros que desenvolvedor comete

Seguranca em APIs nao e um luxo, e uma necessidade. Um unico endpoint mal configurado pode expor dados de milhares de usuarios. Neste guia, voce vai ver os 11 erros mais comuns que desenvolvedores cometem ao construir APIs, e como evita-los. Se voce trabalha com integracoes, este conteudo vai te ajudar a fechar brechas antes que um atacante as explore.

1. Nao usar autenticacao forte

Muitas APIs ainda dependem de chaves estaticas ou tokens que nunca expiram. Isso facilita o trabalho do desenvolvedor, mas tambem o de um invasor. Use OAuth 2.0 ou JWT com expiracao curta e renovacao segura. Uma chave vazada pode ser usada por meses se nao houver revogacao.

2. Expor dados sensiveis na resposta

Retornar o objeto inteiro do banco em uma resposta JSON e um erro comum. Campos como senha, CPF ou cartao de credito nao devem trafegar na resposta. Crie DTOs (Data Transfer Objects) que filtrem apenas o que o cliente precisa. Um exemplo: um endpoint de perfil que retorna o hash da senha junto com o nome do usuario.

3. Nao limitar taxa de requisicoes (rate limiting)

Sem rate limiting, sua API fica vulneravel a ataques de forca bruta e sobrecarga. Um atacante pode tentar milhares de senhas por minuto. Configure limites por IP e por usuario, e retorne 429 quando exceder. Isso protege tanto a autenticacao quanto a disponibilidade geral.

4. Ignorar validacao de entrada

Todo campo recebido pela API deve ser validado, tanto no formato quanto no tipo. Nao confie no front-end. Um campo de ID que aceita strings pode abrir espaco para injecao de SQL ou NoSQL. Use bibliotecas de validacao e nunca concatene entradas diretamente em queries.

5. Esquecer de proteger endpoints internos

Endpoints que deveriam ser internos, como /admin ou /debug, muitas vezes ficam acessiveis publicamente. Se um endpoint nao deve ser chamado por clientes, bloqueie no firewall ou na camada de API gateway. Um exemplo real: uma API que expoe um endpoint de limpeza de cache sem autenticacao.

6. Configurar CORS de forma permissiva

Permitir qualquer origem (Access-Control-Allow-Origin: *) pode facilitar ataques de cross-site request forgery. Configure CORS apenas para dominios conhecidos e use credenciais com cuidado. Em vez de liberar tudo, restrinja a lista de origens confiaveis.

7. Nao criptografar dados em transito

Usar HTTP em vez de HTTPS e um erro grave. Qualquer dado enviado pela rede pode ser interceptado. Sempre use TLS 1.2 ou superior. Nao basta criptografar no banco se o trafego esta em texto puro. Um certificado SSL valido e o minimo.

8. Vazar informacoes em mensagens de erro

Erros detalhados ajudam o desenvolvedor, mas tambem o atacante. Uma mensagem que mostra a stack trace ou o nome do banco de dados e um mapa para explorar a API. Retorne erros genericos ao cliente e registre detalhes no servidor. Por exemplo, em vez de "coluna 'senha' nao encontrada", retorne "erro interno".

9. Nao usar HTTPS em todas as camadas

Mesmo que o front-end use HTTPS, se a API interna comunica por HTTP, ha uma brecha. Garanta que todas as comunicacoes, inclusive entre servicos, usem TLS. Um atacante pode explorar uma conexao interna nao criptografada para roubar tokens.

10. Nao gerenciar permissoes corretamente

Erros de autorizacao sao mais perigosos que os de autenticacao. Um usuario comum pode acessar um endpoint de administrador se a logica de permissao for falha. Implemente controle de acesso baseado em funcoes (RBAC) e teste cada endpoint com diferentes niveis de acesso. Um exemplo: um usuario com perfil 'viewer' consegue deletar registros.

11. Nao monitorar nem registrar atividades

Sem logs, voce nao percebe um ataque ate que seja tarde. Registre todas as requisicoes, especialmente as que falham na autenticacao. Monitore padroes anomalos, como picos de trafego ou acessos a endpoints sensiveis. Ferramentas de observabilidade ajudam a detectar tentativas de invasao.

Como escolher a prioridade de correcao

Se voce nao pode corrigir tudo de uma vez, priorize erros que exponham dados (itens 2, 8 e 10) e os que permitem acesso nao autorizado (itens 1, 5 e 6). Depois, trate os que afetam a disponibilidade (itens 3 e 11). Erros de criptografia (itens 7 e 9) devem ser corrigidos antes de qualquer deploy em producao.

FAQ

Qual e o erro mais comum em seguranca de APIs?

O mais comum e nao validar a entrada do usuario. Muitas APIs aceitam qualquer dado sem checar tipo, tamanho ou formato, o que abre espaco para injecao de SQL e outros ataques. A validacao deve ser feita no servidor, nunca apenas no front-end.

O que e rate limiting e por que importa?

Rate limiting limita o numero de requisicoes que um cliente pode fazer em um periodo. Ele impede ataques de forca bruta e sobrecarga. Sem ele, um atacante pode tentar milhares de senhas ou derrubar o servico com trafego excessivo.

Como proteger endpoints internos de uma API?

Endpoints internos devem ser bloqueados por firewall ou por um API gateway que filtre por IP ou rede. Nunca os exponha publicamente. Se o endpoint nao precisa ser acessado por clientes, ele nao deveria estar na rota publica.

O que e CORS e como configurar corretamente?

CORS (Cross-Origin Resource Sharing) controla quais origens podem acessar sua API. Configure apenas os dominios que voce controla ou confia. Evite usar o curinga (*) e, se precisar de credenciais, defina origens explicitas.

Por que mensagens de erro podem ser um risco?

Mensagens detalhadas revelam estrutura do banco, bibliotecas e caminhos de arquivos. Um atacante usa essas informacoes para planejar ataques. Retorne erros genericos ao cliente e registre o detalhe no log do servidor.

Qual a melhor pratica para autenticacao em APIs?

Use um padrao consolidado como OAuth 2.0 com tokens de curta duracao e refresh tokens. Evite chaves estaticas. Garanta que os tokens sejam revogaveis e que a expiracao seja curta o suficiente para limitar danos em caso de vazamento.