Segurança de APIs: os erros mais comuns em produção

O portal do cliente tem login, a tela só mostra os pedidos da empresa logada e o time de QA testou tudo. Aí alguém abre o inspetor do navegador, vê a chamada GET /api/pedidos/48213, troca o número para 48214 e recebe o pedido de outra empresa, com endereço, itens e condições comerciais.

Nada nesse cenário ilustrativo exige um atacante sofisticado. É o tipo de falha mais comum em APIs de sistemas empresariais, e ela nasce de uma confusão simples: a tela esconder um dado não significa que a API protege esse dado. A seguir, os erros que mais aparecem em produção, usando como roteiro as categorias da lista OWASP API Security Top 10, e o controle de engenharia que previne cada um.

A API é a porta da frente, mesmo sem tela

Durante anos, segurança de aplicação foi pensada a partir da interface: o botão não aparece para quem não pode clicar, o campo fica desabilitado, o menu some. Com aplicações web modernas, aplicativos mobile e integrações com parceiros, a lógica se inverteu. Toda a regra de negócio está exposta por uma API, e qualquer pessoa com um cliente HTTP conversa com ela diretamente, sem passar pela tela.

Isso vale para a API "interna" que só o seu front-end usa. Se o navegador chama, ela é pública. Vale para o aplicativo: o tráfego pode ser inspecionado e as chamadas reproduzidas. E vale para a API de parceiros, que por definição é consumida por código que você não controla; o desenho dela está em API para parceiros e clientes.

A consequência prática é uma regra de arquitetura: toda decisão de autorização acontece no servidor, a cada requisição. A interface pode esconder o que o usuário não pode fazer, por conveniência, mas nunca é a barreira.

Autorização por objeto: o erro número um

A categoria que abre a lista da OWASP é a falha de autorização em nível de objeto (BOLA, na sigla em inglês). É exatamente o exemplo do início: a API verifica se o usuário está autenticado, mas não verifica se aquele objeto específico pertence a ele.

Ela aparece de várias formas:

• Trocar o identificador na URL (/pedidos/48213) ou no corpo da requisição.
• Baixar o boleto, a nota fiscal ou o anexo de outro cliente pelo link direto do arquivo.
• Em plataformas que atendem várias empresas, acessar dados de outro cliente porque a consulta filtra pelo ID do registro e esquece o ID da empresa.

Usar identificadores aleatórios (UUID) em vez de números sequenciais dificulta a adivinhação, mas não corrige nada: identificadores vazam em logs, e-mails e links compartilhados. A correção é estrutural:

1. Toda consulta a um recurso filtra pelo dono, derivado da sessão autenticada, nunca de um parâmetro enviado pelo cliente. Não é "buscar o pedido 48213 e depois checar"; é "buscar o pedido 48213 da empresa desta sessão".
2. A verificação fica num lugar só, numa camada de acesso a dados ou numa política centralizada, e não repetida à mão em cada rota. O esquecimento em uma rota nova é o que produz o incidente.
3. Arquivos são servidos por URLs assinadas e de curta duração, geradas depois da verificação de permissão.
4. Testes automatizados de autorização: para cada endpoint, um teste em que o usuário da empresa A tenta ler, alterar e excluir um recurso da empresa B e precisa receber recusa.

Em sistemas com várias empresas no mesmo banco, esse isolamento é o requisito central da arquitetura, discutido em arquitetura SaaS multi-tenant.

A irmã da autorização por objeto: autorização por função

A quinta categoria da lista é a falha de autorização em nível de função. O usuário comum não vê o menu de administração, mas consegue chamar POST /api/usuarios/{id}/perfil e se promover. Ou chama DELETE num recurso em que só tem permissão de leitura. A correção é a mesma lógica: permissões verificadas no servidor para cada operação, negando por padrão, com um mapa explícito de qual papel pode chamar o quê. O desenho desses papéis está em perfis de acesso e trilha de auditoria.

Autenticação, tokens e sessões

A segunda categoria cobre falhas de autenticação. Em sistemas empresariais, as mais frequentes não são algoritmos quebrados, e sim decisões de conveniência que ficaram:

• Login sem limite de tentativas, permitindo testar senhas vazadas de outros serviços em escala.
• Tokens que não expiram ou que continuam válidos depois de o usuário trocar a senha ou ser desligado.
• Chaves de integração compartilhadas entre vários parceiros, ou coladas no código do aplicativo, onde qualquer um extrai.
• Tokens JWT aceitos sem validar assinatura, emissor, público e expiração, ou com algoritmo escolhido pelo próprio token.
• Recuperação de senha fraca, com links que não expiram ou que revelam se o e-mail existe na base.

O que fazer:

• Use um provedor de identidade maduro e padrões abertos (OAuth 2.0 e OpenID Connect) em vez de escrever autenticação do zero.
• Tokens de acesso de vida curta, com renovação controlada e revogação real: desligar um usuário derruba as sessões dele imediatamente.
• Uma credencial por integração, com escopo mínimo e rotação periódica. Se um parceiro vaza a chave, só ele é afetado.
• Segundo fator de autenticação para perfis administrativos e para quem acessa dados sensíveis.
• Limite de tentativas por conta e por origem, com resposta que não revele se o usuário existe.

Exposição excessiva de dados na resposta

A terceira categoria trata da autorização em nível de propriedade, e junta dois problemas que parecem opostos.

Na leitura, a API devolve demais. O aplicativo precisa mostrar o nome do vendedor e a API devolve o cadastro inteiro: CPF, telefone pessoal, salário, hash de senha. A tela ignora os campos extras, mas eles estão na resposta, visíveis para quem olhar. É comum quando o endpoint serializa a entidade do banco diretamente.

Na escrita, a API aceita demais. O formulário de perfil envia nome e telefone, mas a API aceita qualquer campo do objeto, e alguém adiciona "perfil": "admin" ou "limite_credito": ... ao corpo da requisição. É a chamada atribuição em massa.

A correção nos dois casos é contrato explícito:

• Cada endpoint tem um esquema de resposta que lista os campos devolvidos. Nunca devolva a entidade do banco inteira.
• Cada endpoint de escrita tem um esquema de entrada que lista os campos aceitos. O resto é rejeitado, não ignorado em silêncio.
• Campos que dependem de permissão (dados pessoais, custos, margem) são incluídos conforme o papel de quem pede.
• Mensagens de erro sem detalhes internos: nada de consulta SQL, caminho de arquivo ou pilha de execução na resposta.

Aqui segurança e privacidade se encontram: devolver dado pessoal que a tela não usa contraria o princípio da necessidade da LGPD. O lado de privacidade está em LGPD no desenvolvimento de sistemas.

Limite de uso, abuso e automação maliciosa

Duas categorias da lista tratam de abuso: consumo irrestrito de recursos e acesso irrestrito a fluxos de negócio sensíveis.

Consumo de recursos. Um endpoint de listagem sem paginação máxima, uma busca que aceita filtros que varrem a tabela inteira, um upload sem limite de tamanho, uma exportação de relatório que qualquer usuário dispara em loop. Não precisa ser ataque: um script mal escrito de um parceiro derruba o sistema do mesmo jeito. Controles:

• Limite de requisições por credencial e por origem, com resposta clara quando o limite é atingido.
• Paginação obrigatória com tamanho máximo, tempo máximo de consulta e tamanho máximo de corpo.
• Operações pesadas (relatórios, importações) processadas em fila, com limite de concorrência por cliente.

Fluxos de negócio sensíveis. Aqui o problema não é volume técnico, é uso indevido de uma função legítima: consultar CPF repetidamente para validar uma lista vazada, criar contas em massa para explorar um cupom, reservar todo o estoque de uma promoção por um robô. A defesa é específica de cada negócio: limites por conta, verificação adicional em ações de alto valor, detecção de padrões anômalos e alertas para a operação.

Inventário de APIs e endpoints esquecidos

A nona categoria da lista, gestão inadequada de inventário, é a mais organizacional e a que mais surpreende. Os endpoints que causam incidente frequentemente são os que ninguém lembrava que existiam:

• A versão 1 da API, que continua no ar porque um cliente antigo ainda usa, sem as correções aplicadas na versão 2.
• O endpoint de depuração criado para resolver um problema e nunca removido.
• O ambiente de homologação exposto na internet, com cópia de dados reais de produção.
• A documentação interativa publicada com credenciais de teste que funcionam em produção.

O controle é simples de enunciar e exige disciplina para manter: um inventário vivo, gerado a partir do código, com todos os endpoints, versões, ambientes, quem consome cada um e que dados trafegam. A especificação OpenAPI mantida junto com o código ajuda, porque permite comparar o que está documentado com o que de fato responde. Versões antigas têm data de desativação comunicada aos consumidores. Ambientes de teste não têm dados pessoais reais.

Na mesma linha, a lista inclui a configuração insegura (cabeçalhos de segurança ausentes, CORS liberado para qualquer origem, TLS mal configurado) e o consumo inseguro de APIs de terceiros: tratar a resposta de um parceiro como confiável sem validar, ou seguir redirecionamentos e URLs fornecidas por ele sem restrição, o que abre espaço para requisições forjadas a partir do seu servidor.

Testes de segurança dentro do pipeline

Segurança verificada uma vez por ano num teste de intrusão é melhor do que nada, mas o código muda toda semana. O que funciona é colocar verificações no mesmo pipeline que já compila e testa o sistema:

• Testes de autorização como testes de unidade e de integração, escritos junto com cada endpoint. É o controle mais eficaz contra os dois erros mais comuns.
• Análise de dependências para detectar bibliotecas com vulnerabilidades conhecidas, com atualização planejada.
• Análise estática do código em busca de padrões perigosos e segredos commitados por engano.
• Validação do contrato: a resposta real de cada endpoint confere com o esquema declarado, pegando campos extras que vazaram.
• Varredura dinâmica no ambiente de homologação a cada versão relevante.

Testes de intrusão feitos por especialistas continuam valendo, principalmente antes de abrir uma API para parceiros ou depois de mudanças grandes. Mas eles funcionam melhor quando encontram um sistema em que o básico já é verificado automaticamente.

Como saber se está funcionando

• Todo endpoint tem pelo menos um teste de acesso cruzado entre clientes.
• O inventário de endpoints bate com o que responde em produção.
• Nenhuma credencial de integração é compartilhada entre parceiros.
• Existe alerta para picos de respostas de acesso negado, sinal típico de alguém testando identificadores.
• Vulnerabilidades em dependências têm prazo interno de correção definido por severidade, e ele é cumprido.

Checklist rápido para revisar a sua API

• A autorização acontece no servidor, filtrando pelo dono a partir da sessão?
• Existe teste automatizado de acesso a recurso de outro cliente?
• Tokens expiram e podem ser revogados na hora?
• As respostas seguem um esquema explícito, sem devolver a entidade inteira?
• A escrita rejeita campos não previstos?
• Há limite de requisições, paginação máxima e fila para operações pesadas?
• Você tem um inventário atualizado de endpoints, versões e ambientes?
• O pipeline verifica dependências, segredos e contratos a cada mudança?

Se alguma resposta for "não sei", comece por ela.

Segurança que nasce no desenho da API

Na Pervian Tech, APIs são projetadas com autorização centralizada, contratos explícitos, limites de uso e testes de acesso cruzado desde o primeiro endpoint, como parte do nosso trabalho de arquitetura de software. Também revisamos APIs existentes para encontrar essas falhas antes de alguém de fora encontrar.

Cada sistema é sob medida, e o investimento é definido sob consulta, depois de um diagnóstico inicial gratuito em que entendemos a sua API, quem a consome e que dados ela expõe. Se você suspeita que a sua API confia demais na tela, fale com a gente.