11 erros de segurança em API REST que você comete

Proteger uma API REST não é apenas sobre adicionar uma camada de autenticação. É sobre evitar um conjunto de erros que, juntos, transformam sua aplicação em um convite para ataques. Nós listamos os 11 erros de segurança em API REST que você comete, e como corrigir cada um deles com ações práticas.

1. Ignorar a criptografia TLS em todas as comunicações

A primeira linha de defesa de qualquer API REST é o TLS. Sem ele, os dados trafegam em texto puro e qualquer interceptação na rede, em um Wi-Fi público, por exemplo, expõe credenciais, tokens e payloads inteiros. O erro não é apenas não usar TLS, mas também usar versões obsoletas (TLS 1.0 ou 1.1) ou não forçar redirecionamento de HTTP para HTTPS.

Correção: Configure seu servidor para aceitar apenas TLS 1.2 ou superior e redirecione todo tráfego HTTP para HTTPS. Ferramentas como Let's Encrypt facilitam a obtenção de certificados gratuitos. Teste com curl -v https://sua-api.com para confirmar que a negociação TLS está ativa.

2. Autenticação fraca ou inexistente

Muitas APIs REST ainda expõem endpoints sem qualquer verificação de identidade. Ou, quando implementam, usam esquemas como Basic Auth sem criptografia adicional, ou senhas fixas embutidas no código. Isso abre porta para acesso não autorizado direto.

Correção: Implemente autenticação baseada em tokens, como JWT (JSON Web Tokens), com expiração curta (15-30 minutos) e renovação via refresh token. Nunca armazene senhas em texto plano, use hashing com bcrypt. Para endpoints críticos, considere autenticação multifator (MFA).

3. Expor dados sensíveis nas respostas da API

Um erro clássico: a API retorna o objeto completo do banco, incluindo campos como senha hash, tokens internos, números de cartão ou CPF, mesmo quando o frontend não precisa deles. Isso vaza informação sigilosa em logs, ferramentas de debugging e para qualquer cliente que faça uma requisição.

Correção: Use DTOs (Data Transfer Objects) para mapear apenas os campos necessários para cada endpoint. Nunca serialize entidades do banco diretamente. Revise cada resposta da API com uma ferramenta como Postman ou Insomnia para garantir que nenhum campo sensível esteja visível.

4. Não validar entrada do usuário

Injeção de SQL, NoSQL, XML ou comandos do sistema ainda acontece porque a API confia no que recebe do cliente. Um parâmetro malicioso pode derrubar o banco, extrair dados ou executar código arbitrário.

Correção: Valide e sanitize toda entrada no servidor, nunca confie no frontend. Use bibliotecas de validação como Joi (Node.js), Pydantic (Python) ou Bean Validation (Java). Para consultas ao banco, prefira ORMs com parâmetros preparados (prepared statements) em vez de concatenar strings.

5. Autorização insuficiente por recurso

Autenticação verifica quem você é. Autorização verifica o que você pode fazer. Um erro comum é autenticar o usuário, mas permitir que ele acesse recursos de outros usuários (por exemplo, alterar o ID na URL para ver dados alheios). Isso é chamado de IDOR (Insecure Direct Object Reference).

Correção: Implemente controle de acesso baseado em função (RBAC) ou em atributos (ABAC). Para cada endpoint, verifique não só se o token é válido, mas se o usuário tem permissão para aquele recurso específico. Teste manualmente com tokens de diferentes perfis.

6. Ausência de rate limiting e throttling

Sem limites de requisição, sua API fica vulnerável a ataques de força bruta, DDoS e scraping. Um atacante pode tentar milhões de senhas em poucos minutos ou sobrecarregar o servidor.

Correção: Configure rate limiting por IP, por token de usuário e por endpoint. Use bibliotecas como express-rate-limit (Node.js) ou middleware de API gateway. Defina limites razoáveis (ex.: 100 requisições por minuto por usuário) e retorne o cabeçalho Retry-After quando excedido.

7. Logar informações sensíveis

Logs são essenciais para debugging, mas quando contêm tokens, senhas ou dados pessoais, tornam-se um risco de segurança. Se o sistema de logs for comprometido, o atacante ganha acesso a tudo.

Correção: Nunca logue o corpo completo de requisições ou respostas. Use máscaras para campos sensíveis (ex.: [FILTERED]). Configure níveis de log (info, warn, error) e evite logar em produção o que é útil apenas em desenvolvimento. Ferramentas como Winston ou Logback permitem filtros customizados.

8. Ignorar a segurança de tokens de acesso

JWT é popular, mas mal configurado: tokens sem expiração, assinatura com algoritmo none, chave secreta fraca ou armazenada em código-fonte. Um token roubado vira acesso permanente.

Correção: Use algoritmos de assinatura fortes (HS256 ou RS256). Defina expiração curta (15-30 min) e use refresh tokens com rotação. Armazene a chave secreta em variáveis de ambiente ou em um cofre (HashiCorp Vault, AWS Secrets Manager). Nunca aceite tokens com algoritmo none.

9. Não versionar a API

Mudanças na API sem versionamento quebram clientes existentes e forçam atualizações urgentes. Pior: versões antigas podem conter vulnerabilidades não corrigidas.

Correção: Adicione um prefixo de versão na URL (/v1/, /v2/) ou no cabeçalho Accept. Mantenha versões antigas por um período definido (ex.: 6 meses) e comunique a descontinuação com antecedência. Documente cada versão com changelog.

10. Falta de validação de CORS

Configuração permissiva de CORS (Access-Control-Allow-Origin: *) permite que qualquer site faça requisições à sua API. Isso abre brecha para ataques CSRF e vazamento de dados.

Correção: Configure CORS para permitir apenas origens específicas e confiáveis. Nunca use * em produção. Para endpoints que não precisam ser acessados por navegadores, bloqueie CORS completamente. Teste com ferramentas como cors-test.

11. Não monitorar nem auditar a API

Sem logs de acesso, sem alertas de tentativas suspeitas, sem auditoria de quem fez o quê. Quando um incidente acontece, não há rastro para investigar.

Correção: Implemente logging estruturado de todas as requisições (método, endpoint, status, tempo de resposta, IP de origem). Use ferramentas de monitoramento como Prometheus + Grafana ou serviços gerenciados (AWS CloudWatch, Datadog). Configure alertas para padrões anômalos (ex.: 10 falhas de autenticação em 1 minuto).

Como escolher as correções mais urgentes

Se você tem recursos limitados, comece pelos erros 1 a 5 (TLS, autenticação, dados expostos, validação de entrada, autorização). Eles cobrem 80% dos ataques comuns. Depois, avance para rate limiting e tokens seguros. O monitoramento contínuo (item 11) deve vir junto desde o início, mesmo que simples.

FAQ sobre segurança em API REST

Qual a diferença entre autenticação e autorização em API REST?

Autenticação verifica a identidade do usuário (quem é). Autorização define o que esse usuário pode fazer (acesso a recursos). Uma API pode autenticar corretamente, mas falhar na autorização, permitindo que um usuário veja dados de outro.

Devo usar JWT ou OAuth 2.0?

JWT é um formato de token. OAuth 2.0 é um protocolo de autorização que pode usar JWT como token. Para APIs REST, OAuth 2.0 com JWT é a combinação mais segura e flexível, especialmente se você tem múltiplos clientes (web, mobile, terceiros).

Como prevenir ataques de injeção em API REST?

Valide e sanitize toda entrada no servidor. Use prepared statements ou ORMs para consultas ao banco. Nunca concatene strings para montar queries. Para XML, evite parsers que expandem entidades externas (XXE).

O que é rate limiting e por que é importante?

Rate limiting limita o número de requisições que um cliente pode fazer em um intervalo de tempo. É importante para evitar ataques de força bruta, DDoS e consumo abusivo de recursos. Deve ser aplicado por IP, token de usuário e endpoint.

Preciso criptografar dados em repouso na API REST?

Sim. Dados armazenados (em banco, cache ou arquivos) devem ser criptografados com AES-256 ou similar. Isso protege contra vazamento se o armazenamento for comprometido. A criptografia em trânsito (TLS) cobre apenas a comunicação.

Como testar a segurança da minha API REST?

Use ferramentas como OWASP ZAP, Burp Suite ou Postman com coleções de segurança. Faça testes manuais de IDOR, injeção e autenticação. Considere contratar um pentest profissional para APIs críticas.