Segurança de APIs: protegendo seus endpoints

APIs são a espinha dorsal de praticamente todo app moderno construído com IA: o front-end conversa com o back-end por elas, integrações dependem delas e dados sensíveis trafegam por elas. Justamente por serem a porta de entrada, são também o alvo preferido de atacantes. Neste guia você vai conhecer as camadas essenciais para proteger seus endpoints — da autenticação à observabilidade — e os erros mais comuns que abrem brechas.

Por que APIs são um alvo tão visado

Diferente de uma interface web pensada para humanos, uma API é projetada para ser consumida por máquinas, de forma programática e em grande volume. Isso significa que um atacante pode automatizar tentativas, varrer endpoints e explorar falhas em escala. Se você ainda está construindo sua base conceitual, vale começar por O que é uma API? Definição clara para iniciantes e depois voltar a este guia com o vocabulário firme.

A segurança de API não é um único recurso, e sim um conjunto de camadas que se reforçam. Confiar em apenas uma — só autenticação, por exemplo — deixa flancos abertos. Esse princípio é conhecido como defesa em profundidade: cada camada assume que as outras podem falhar e ainda assim oferece proteção. Vamos percorrer as principais.

O modelo de superfície de ataque de uma API

Antes das camadas, vale visualizar onde estão os riscos. Cada endpoint que recebe entrada do usuário é uma porta. Cada parâmetro é uma fechadura que pode estar mal feita. A superfície inclui não só as rotas documentadas, mas também:

Pensar a API como superfície, e não como rotas isoladas, é o que evita aquela falha esquecida que derruba todo o resto. Atacantes mapeiam essa superfície exatamente como descrito em Reconhecimento (recon): a fase mais importante do pentest — então pense como eles para defender melhor.

Camada 1: Autenticação forte

Autenticação responde "quem está chamando esta API?". Os mecanismos mais usados hoje:

A RFC 7519 (Jones, Bradley, Sakimura, 2015) padroniza os tokens JWT que sustentam boa parte dessas estratégias. Independente do método, a regra é: autentique no servidor, valide a assinatura e os claims do token, e nunca confie em identidade vinda do cliente sem verificação.

GET /api/v1/pedidos HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiI...

Armadilhas comuns de JWT

JWT é poderoso, mas tem pegadinhas que aparecem em auditorias com frequência:

Para sessões longas, prefira access tokens de vida curta combinados com refresh tokens revogáveis, em vez de um único token eterno.

Camada 2: Autorização correta em cada endpoint

Autenticar não basta: depois de saber quem é o usuário, você precisa decidir o que ele pode fazer. Um dos erros mais graves e comuns em APIs é a autorização quebrada em nível de objeto — quando o usuário A consegue acessar o recurso do usuário B só trocando um ID na URL.

GET /api/v1/faturas/1042   <- minha fatura
GET /api/v1/faturas/1043   <- fatura de OUTRO usuário (deveria ser 403!)

A defesa é checar, no servidor e em cada requisição, se o usuário autenticado realmente é dono do recurso solicitado. Nunca dependa de o front-end "não mostrar" o botão. O OWASP ASVS (OWASP Foundation, 2021) trata esse controle como requisito central de verificação de segurança.

IDOR, BOLA e o problema dos IDs sequenciais

Essa classe de falha aparece nas referências de segurança como IDOR (Insecure Direct Object Reference) ou, no vocabulário específico de APIs, BOLA (Broken Object Level Authorization) — consistentemente o risco número um do OWASP API Security Top 10. A causa raiz é sempre a mesma: o servidor confia no ID enviado pelo cliente sem confirmar a propriedade do objeto.

Algumas defesas práticas:

# Ruim: confia no ID e não checa propriedade
fatura = db.get_fatura(id=request_id)
return fatura

# Bom: vincula a consulta ao usuário autenticado
fatura = db.get_fatura(id=request_id, user_id=usuario_autenticado.id)
if fatura is None:
    return resposta(404)  # não revela se o recurso existe
return fatura

Repare no 404 em vez de 403: revelar que o recurso existe (mas é de outro) já entrega informação ao atacante.

Camada 3: Validação e sanitização de entrada

Toda entrada vinda do cliente é não confiável até prova em contrário. Falhas de validação levam a injeções (SQL, comandos, NoSQL) e a comportamentos inesperados. As práticas essenciais:

# Ruim: vulnerável a SQL injection
db.execute(f"SELECT * FROM users WHERE email = '{email}'")

# Bom: consulta parametrizada
db.execute("SELECT * FROM users WHERE email = %s", (email,))

Validação por schema na borda

A forma mais robusta de validar é definir um schema explícito para cada endpoint e rejeitar qualquer requisição que não o satisfaça, antes de qualquer lógica de negócio. Isso centraliza a validação na borda da API e garante que o restante do código trabalhe apenas com dados já confiáveis:

# Exemplo com Pydantic (Python)
from pydantic import BaseModel, EmailStr, conint

class CriarPedido(BaseModel):
    email: EmailStr
    quantidade: conint(gt=0, le=100)
    cupom: str | None = None

Se o corpo da requisição não bater com o schema, a requisição falha com 422 antes de tocar o banco. O mesmo vale para validar tipos numéricos, comprimentos máximos de string e formatos de data. Tratar a entrada com rigor na borda elimina classes inteiras de bug de uma vez.

Camada 4: Rate limiting e proteção contra abuso

Rate limiting restringe quantas requisições um cliente pode fazer em um intervalo de tempo. Sem ele, sua API fica exposta a:

Estratégias comuns incluem limitar por IP, por API key ou por usuário autenticado, usando algoritmos como token bucket ou janela deslizante. Quando o limite é excedido, responda com o status apropriado:

HTTP/1.1 429 Too Many Requests
Retry-After: 60

Combine rate limiting com bloqueio temporário após várias falhas de autenticação para frustrar ataques automatizados.

Escolhendo a chave e o algoritmo

A escolha da chave de limitação importa tanto quanto o limite em si. Limitar só por IP pune usuários atrás de um mesmo NAT corporativo e é facilmente burlado por quem rotaciona IPs. O ideal é combinar dimensões: por usuário autenticado para endpoints sensíveis, por IP para rotas públicas, e por API key para integrações.

Quanto aos algoritmos:

Exponha cabeçalhos como X-RateLimit-Remaining para que clientes bem-comportados se autorregulem, reduzindo o tráfego de erro.

Camada 5: Transporte seguro e cabeçalhos

Toda comunicação com a API deve trafegar exclusivamente sobre HTTPS. Dados em texto puro na rede podem ser interceptados, incluindo tokens de autenticação. Além disso:

CORS sem furos

CORS (Cross-Origin Resource Sharing) é fonte recorrente de configuração perigosa. Os erros clássicos:

Mantenha uma allowlist explícita de origens confiáveis e valide a correspondência exata. CORS é um controle do navegador, não substitui autorização no servidor — mas mal configurado abre vetores reais.

Os erros mais comuns que expõem APIs

Vale conhecer os padrões de falha mais frequentes, muitos deles catalogados no OWASP Top 10 explicado: as 10 maiores falhas de segurança web:

Mass assignment na prática

O mass assignment merece destaque porque é traiçoeiro. Muitos frameworks mapeiam automaticamente o JSON recebido para os campos de um modelo. Se o cliente enviar um campo extra que existe no modelo mas não deveria ser editável, ele é gravado:

{ "nome": "Ana", "email": "ana@exemplo.com", "role": "admin" }

Se o servidor faz usuario.update(**dados) sem filtrar, o usuário acabou de se promover a admin. A defesa é validar quais campos são editáveis por meio de um schema explícito (como o da Camada 3), nunca aceitando o corpo bruto direto no modelo.

Observabilidade: enxergar o ataque acontecendo

Defender é também detectar. Registre eventos de segurança relevantes — falhas de autenticação, acessos negados, picos de tráfego — sem nunca logar dados sensíveis como senhas ou tokens completos. Logs estruturados e alertas permitem que você perceba um ataque em andamento em vez de descobri-lo semanas depois pelo vazamento.

Monitore métricas como taxa de respostas 401/403, latência anormal e volume de 429. Um aumento súbito nessas taxas costuma ser o primeiro sinal de uma campanha automatizada contra seus endpoints.

Boas práticas de log seguro:

Segurança no ciclo de vida da API

As camadas que vimos protegem a API em execução, mas a segurança começa muito antes do primeiro deploy e continua depois dele. Pensar no ciclo de vida completo evita que falhas entrem silenciosamente:

Tratar segurança como um portão de qualidade contínuo, e não como uma auditoria pontual antes do lançamento, é o que mantém a postura defensiva ao longo da evolução do produto.

Versionamento e depreciação seguros

APIs evoluem, e versões antigas tendem a virar dívida de segurança esquecida. Adote uma política explícita: documente quais versões estão suportadas, comunique prazos de depreciação aos consumidores e desative de fato as versões antigas no servidor, não apenas na documentação. Uma rota /api/v1 que continua respondendo dois anos depois do lançamento da v2, sem receber correções, é exatamente o tipo de endpoint esquecido que atacantes procuram.

Um checklist prático

Antes de colocar uma API em produção, confirme:

Perguntas frequentes

JWT ou sessão no servidor? Depende. JWT brilha em arquiteturas distribuídas e sem estado, mas dificulta revogação imediata. Sessões no servidor são triviais de revogar, ao custo de armazenamento compartilhado. Muitos sistemas combinam os dois: JWT de vida curta + refresh token revogável.

Rate limiting resolve DoS? Reduz DoS na camada de aplicação e ataques de força bruta, mas não substitui proteção de infraestrutura (CDN, WAF) contra DDoS volumétrico.

API key é suficiente para autenticar? Para identificar uma aplicação, sim; para autenticar um usuário com permissões granulares, não. API keys são estáticas e, se vazadas, dão acesso pleno até a rotação. Trate-as como segredos e combine com escopos.

Preciso validar entrada se uso um ORM? Sim. O ORM protege contra SQL injection em consultas parametrizadas, mas não valida regras de negócio, tipos, tamanhos nem impede mass assignment. Validação por schema continua necessária.

Conclusão

Segurança de API não é um produto que você compra, e sim um conjunto de camadas que se reforçam: autenticação forte, autorização verificada em cada requisição, validação rigorosa de entrada, rate limiting, transporte seguro e observabilidade. Os ataques mais comuns exploram justamente a ausência de uma dessas camadas — uma autorização esquecida, uma entrada não validada, um campo de mass assignment aberto, um segredo vazado. Trate cada endpoint como uma porta que precisa de fechadura, vigia e registro, adote defesa em profundidade para que a falha de uma camada não derrube as outras, e suas APIs estarão à frente da maioria das aplicações por aí.

Referências