11 Padrões de Segurança para APIs Públicas

Segurança em APIs públicas não se resolve com uma única camada. Na prática, vejo times tratando autenticação como suficiente e deixando endpoints expostos a abusos. Reuni 11 padrões que uso como checklist, do mais crítico ao complementar, com um critério concreto para cada um.

1. Autenticação forte e obrigatória

Toda API pública deveria exigir credencial válida, mesmo em endpoints de leitura. Chaves de API estáticas são um começo, mas tokens de curta duração (OAuth 2.0 com expiração) reduzem o dano de um vazamento. Critério: se um token vaza, ele deve expirar em minutos, não em meses.

2. Autorização por escopo e recurso

Autenticar não é autorizar. Um token válido não pode acessar dados de outro usuário. Aplique verificação de propriedade em cada requisição, não apenas no login. Exemplo: um endpoint /pedidos/{id} deve checar se o id pertence ao token que chamou.

3. Rate limiting e cotas

Sem limite de requisições, um script derruba seu serviço ou extrai sua base. Defina limites por chave, IP e usuário. Critério: comece com 60 requisições por minuto por chave e ajuste conforme o uso real.

4. Validação de entrada e saída

Nunca confie no payload recebido. Valide tipo, tamanho e formato antes de processar. Na saída, filtre campos sensíveis. Um erro comum é devolver o objeto inteiro do banco, incluindo hash de senha ou CPF.

5. Criptografia em trânsito

TLS 1.2 ou superior é o mínimo. Redirecione HTTP para HTTPS e desative cifras antigas. Sem isso, qualquer intermediário lê credenciais e dados.

6. Gestão de segredos

Chaves e tokens não pertencem ao código-fonte. Use cofre de segredos com rotação periódica. Critério: se uma chave está no Git, considere-a comprometida e rotacione.

7. Registro e monitoramento

Log sem dados sensíveis, mas com rastreio de quem chamou o quê. Alertas para picos de erro 401 e 429 ajudam a detectar abuso antes do incidente.

8. Limitação de payload e timeout

Defina tamanho máximo de corpo e tempo de resposta. Um payload de 10 MB repetido mil vezes consome memória e derruba o serviço.

9. Versionamento e depreciação

Versione a API desde o início. Ao descontinuar, avise com antecedência e mantenha a versão antiga por um período definido.

10. Documentação com avisos de segurança

Documente limites, escopos e erros. Isso reduz chamadas erradas e facilita que integradores sigam as regras.

11. Testes de segurança contínuos

Inclua testes de autorização e injeção no pipeline. Uma verificação automatizada a cada deploy pega regressões que a revisão manual deixa passar.

Para quem está começando, priorize os itens 1 a 4: eles cobrem a maior parte do risco real. Os demais entram conforme a API ganha exposição.

Perguntas frequentes

O que é segurança de APIs públicas?

É o conjunto de controles que protege endpoints expostos contra acesso indevido, abuso e vazamento. Envolve autenticação, autorização, limites de uso, validação e monitoramento, aplicados em camadas complementares.

Qual o padrão mais importante?

Autenticação forte aliada à autorização por recurso. Sem elas, os outros controles perdem efeito, pois um token válido pode acessar dados que não deveria.

Rate limiting resolve ataques?

Reduz abuso e força bruta, mas não substitui validação e autorização. É uma camada entre várias, útil contra extração massiva e negação de serviço.

Preciso de OAuth 2.0 em toda API?

Não necessariamente. APIs internas ou de leitura simples podem usar chaves com escopo limitado. OAuth faz mais sentido quando há usuários e delegação de acesso.

Como testar a segurança da minha API?

Automatize testes de autorização, injeção e limites no pipeline. Some a isso revisões periódicas e monitoramento de erros 401 e 429 em produção.