Bases de segurança de APIs que toda a equipa SaaS deve dominar

As APIs transportam hoje a maior parte do tráfego que testamos, e falham de forma diferente das páginas web que substituíram. Uma aplicação de navegador esconde coisas não as desenhando; uma API não tem essa ilusão. Todos os endpoints são diretamente alcançáveis, todos os parâmetros são diretamente editáveis, e o cliente está inteiramente sob controlo do atacante.

Quatro controlos evitam a grande maioria das constatações graves em APIs. Nenhum é difícil. São apenas fáceis de deixar para depois.

1. Autentique todos os endpoints, incluindo os esquecidos

A forma mais comum de a autenticação falhar numa API não é um algoritmo quebrado. É um endpoint que nunca foi ligado ao middleware — uma verificação de saúde que cresceu para diagnóstico, uma rota de serviço interno exposta pelo mesmo gateway, uma versão antiga deixada a correr depois da v2, um recetor de webhook que confia em tudo o que lhe chega.

Enumere o que expõe realmente, não o que julga expor. Gere a lista de rotas a partir da framework, compare-a com a API documentada e confirme que todas rejeitam um pedido não autenticado. Quando um webhook tem mesmo de aceitar chamadas externas, verifique uma assinatura — um segredo partilhado num cabeçalho não é assinatura e não sobrevive a ser registado.

Se emite JWT: valide o algoritmo contra uma lista de permitidos em vez de confiar no cabeçalho do próprio token, verifique emissor e destinatário, e mantenha os tokens de acesso curtos com renovação do lado do servidor. Um token que não consegue revogar é uma credencial que não consegue retirar.

2. Autorize ao nível do objeto, sempre

É este o ponto que produz as violações graves. A autenticação responde a «quem é você»; a autorização ao nível do objeto responde a «pode aceder a este registo em concreto». A segunda pergunta é feita com muito menos consistência do que a primeira.

A falha parece banal: GET /api/v2/encomendas/88213 devolve uma encomenda de outro cliente, porque o código a procurou pela chave primária e verificou apenas que havia sessão. É trivial de explorar — incrementar o número — e trivial de automatizar sobre toda a gama.

A correção fiável é tornar o inquilino parte obrigatória de todas as consultas, em vez de uma verificação posterior. Limite ao nível dos dados, de modo a que uma procura só pelo identificador não consiga devolver a linha de outro inquilino: segurança ao nível da linha na base de dados, ou uma camada de repositório que recusa consultas não limitadas. Verificações dentro dos controladores são esquecidas no controlador seguinte que alguém escrever.

O mesmo vale para propriedades, não só para objetos. Se o endpoint de atualização associa todo o corpo do pedido ao modelo, quem chama pode definir perfil ou id_conta mesmo que a interface nunca o ofereça. Aceite uma lista explícita de campos permitidos por endpoint.

3. Limite tentativas, e limite as certas

A limitação de tentativas é normalmente vista como controlo de disponibilidade. Numa API é igualmente um controlo de acesso: é o que transforma «um registo exposto» em «um registo exposto» em vez de «toda a tabela de clientes enumerada durante a noite».

Limite por identidade autenticada e por endereço, e aplique limites mais apertados aos endpoints que importam: autenticação, recuperação de palavra-passe, emissão de tokens, pesquisa, exportação e tudo o que aceite um identificador. Devolva HTTP 429 com cabeçalho Retry-After para que clientes legítimos recuem corretamente. E limite a paginação — um endpoint que aceita limit=100000 é um endpoint de exportação, quer o tenha pretendido ou não.

4. Diga menos nos erros e nas respostas

As APIs perdem informação por excesso de verbosidade. Um endpoint de autenticação que distingue «utilizador desconhecido» de «palavra-passe errada» é uma ferramenta de enumeração. Um rasto de exceção numa resposta 500 revela versões e caminhos de ficheiros. E o caso silencioso: serializar o registo completo da base de dados e deixar o cliente mostrar uma parte. Não é o cliente que esconde — tudo o que envia é visível. Devolva apenas os campos de que o endpoint precisa, definidos explicitamente.

Por onde começar

Se está a olhar para esta lista e a pensar no que fazer segunda-feira: pegue nos cinco endpoints com mais tráfego e nos cinco mais recentes. Para cada um, confirme que recusa uma chamada não autenticada, que não devolve nada para o identificador de outro inquilino, que recusa um pedido de página excessiva e que devolve apenas os campos previstos. Esse exercício demora uma tarde e encontra mais do que a maioria dos scanners.

A autorização ao nível do objeto é o controlo que merece a sua atenção primeiro. Nos nossos dados de intervenções é simultaneamente o controlo de API mais vezes em falta e o responsável pelas maiores exposições de dados que reportamos.