Segurança de APIs: checklist inicial para proteção eficiente

APIs são o tecido conectivo de aplicações modernas, mas também representam um dos vetores de ataque mais explorados atualmente. Um levantamento setorial recente aponta que a gestão de segurança de APIs continua deficitária na maioria das organizações [4]. Este checklist reúne os controles mínimos que qualquer equipe deve avaliar antes ou logo após colocar uma API em produção, ancorado nas orientações de referências como a Cartilha de Segurança para Internet do CERT.br [1][2].

Por que um checklist específico para APIs

A superfície de ataque exposta por uma API é diferente daquela de uma aplicação web convencional. Enquanto interfaces gráficas impõem determinadas barreiras de interação, APIs aceitam solicitações estruturadas que podem ser automatizadas, testadas e exploradas em escala por ferramentas de brute force, scanners de vulnerabilidade e bots. O relatório de gestão e segurança de APIs de 2024 destaca que grande parte dos incidentes envolvendo APIs decorre da ausência de controles básicos, não de falhas criptográficas avançadas [4]. Um checklist organizado permite que equipes de desenvolvimento e segurança caminhem por uma sequência lógica de verificações, reduzindo a chance de esquecer controles críticos em meio à pressão por entregas. Além disso, a padronização de boas práticas é recomendada por documentos como o Guia de Boas Práticas de Segurança da FEBRABAN [3], que embora voltado ao setor financeiro, estabelece princípios aplicáveis a qualquer segmento.

Inventário e documentação de endpoints

O primeiro passo de qualquer checklist de segurança de APIs é saber exatamente o que está exposto. Muitas organizações descobrem endpoints legados, de depuração ou de testes que permaneceram acessíveis em produção sem nenhum controle. É necessário manter um inventário atualizado de todas as APIs, incluindo versões descontinuadas, endpoints internos e aqueles consumidos por terceiros. Para cada endpoint, registre o método HTTP aceito, os parâmetros esperados, o formato de resposta e o nível de sensibilidade dos dados trafegados. A documentação deve ser tratada como um artefato de segurança, não apenas como material de apoio ao desenvolvedor. APIs não documentadas, frequentemente chamadas de shadow APIs, constituem um risco significativo porque escapam de qualquer processo de revisão ou monitoramento. Ferramentas de descoberta automatizada podem auxiliar, mas o inventário deve ser validado periodicamente por pessoas que entendam o contexto de negócio de cada interface.

Autenticação robusta e gestão de credenciais

Toda API deve exigir autenticação, sem exceções. A escolha do mecanismo depende do cenário: OAuth 2.0 com fluxos apropriados para cada caso de uso, tokens JWT bem configurados ou chaves de API para integrações máquina-a-máquina menos complexas. O CERT.br, em seus fascículos sobre contas e senhas e autenticação em duas etapas [1][5], reforça que credenciais fracas são um dos principais fatores de comprometimento, princípio que se estende diretamente a tokens e chaves de API. Chaves de API estáticas devem ser evitadas em cenários de maior risco, pois não permitem revogação granular nem escopo definido. Tokens JWT devem ter assinatura verificável, tempo de expiração curto e campos como iss, aud e sub devidamente preenchidos. Credenciais não podem ser passadas na URL, pois ficam registradas em logs de servidor, proxies e caches. Headers de autorização ou bodies criptografados são os locais adequados.

Controle de autorização e principle of least privilege

Autenticação identifica quem está fazendo a requisição; autorização determina o que esse sujeito pode fazer. O erro mais comum é confiar que, uma vez autenticado, o consumidor tem permissão para acessar qualquer recurso. Cada endpoint deve verificar explicitamente se o token ou identidade apresentada possui o escopo necessário para aquela operação específica. Isso inclui verificar não apenas o papel do usuário, mas também o contexto: um usuário pode ter acesso a ler seus próprios dados, mas não os de outro. APIs que atendem múltiplos tenants devem implementar isolamento lógico de dados, garantindo que um cliente nunca consiga acessar informações de outro por manipulação de identificadores. O princípio do menor privilégio deve ser aplicado rigorosamente: conceder apenas as permissões estritamente necessárias para cada integração e revisar essas permissões periodicamente.

Validação de entrada e proteção contra injeção

Dados recebidos por uma API nunca devem ser confiáveis. Toda entrada, seja em parâmetros de query, path, headers ou corpo da requisição, deve ser validada contra um schema estrito que defina tipos, formatos, tamanhos e valores permitidos. Essa validação deve ocorrer o mais cedo possível no pipeline de processamento, rejeitando requisições que não atendam aos critérios antes que cheguem à lógica de negócio ou a camadas de persistência. SQL injection, NoSQL injection, XML External Entity (XXE) e injeção de comandos continuam exploráveis em APIs que não sanitizam adequadamente suas entradas. A Cartilha do CERT.br aborda a importância de reconhecer e tratar entradas maliciosas como parte da defesa contra códigos maliciosos [1][6]. A regra fundamental é: não confie no cliente. Se um campo espera um inteiro entre 1 e 100, rejeite qualquer coisa que fuja desse intervalo, retornando um erro sem revelar detalhes internos da validação.

Rate limiting, throttling e proteção contra abuso

APIs sem limites de requisição estão sujeitas a ataques de negação de serviço, brute force de credenciais e enumeração de dados. Implementar rate limiting por consumidor, por IP ou por token é essencial para mitigar esses riscos. O limite deve ser calibrado de acordo com o uso legítimo esperado: uma API de consulta pública pode tolerar taxas diferentes de uma API de transação financeira. Throttling progressivo, onde requisições excessivas resultam em atrasos crescentes em vez de bloqueio imediato, pode ser uma estratégia complementar. Além disso, mecanismos de detecção de anomalias podem identificar padrões de tráfego que sugerem automação maliciosa, como requisições em sequência numérica indicando enumeração de identificadores de recursos. Logs de requisições limitadas devem ser mantidos para apoiar investigações, conforme princípios de rastreabilidade recomendados em boas práticas de segurança [3].

Criptografia em trânsito e em repouso

Toda comunicação com APIs deve usar HTTPS com configurações de TLS adequadas. Isso significa desabilitar versões obsoletas do protocolo (SSLv3, TLS 1.0, TLS 1.1), usar cipher suites fortes e garantir que certificados sejam válidos e gerenciados por uma autoridade certificadora confiável. Headers de segurança como HSTS, Content-Security-Policy e X-Content-Type-Options devem estar presentes nas respostas. Para dados em repouso, informações sensíveis armazenadas por APIs — tokens de sessão, dados pessoais, credenciais de terceiros — devem ser criptografados no banco de dados ou no serviço de armazenamento. O Guia de Boas Práticas de Segurança da FEBRABAN [3] enfatiza a criptografia como camada essencial de proteção, especialmente em cenários regulados. Chaves criptográficas devem ser gerenciadas por um serviço dedicado (KMS), nunca hardcoded no código-fonte ou em variáveis de ambiente sem proteção adicional.

Tratamento seguro de erros e logging estruturado

Respostas de erro em APIs frequentemente vazam informações sensíveis: stack traces, nomes de tabelas, versões de frameworks, caminhos de arquivos internos e detalhes de configuração de banco de dados. Toda API deve ter uma camada de tratamento de erro que padronize as respostas de falha, expondo apenas mensagens genéricas e códigos de erro significativos para o consumidor, enquanto registra os detalhes técnicos em logs internos. Os logs, por sua vez, devem conter timestamp, identificador do consumidor, endpoint acessado, método HTTP, código de resposta e metadata relevante, sem armazenar dados sensíveis como senhas ou tokens completos. Essa prática alinha-se com as recomendações do CERT.br sobre rastreabilidade e detecção de incidentes [1][2]. Logs bem estruturados são a base para detecção de ataques, análise forense e atendimento a requisitos regulatórios.

Versionamento e descontinuação controlada de APIs

APIs evoluem, e a gestão do ciclo de vida das versões é uma questão de segurança. Quando uma nova versão corrige uma vulnerabilidade ou altera o modelo de autorização, a versão antiga deve ter um plano de descontinuação claro, com comunicação antecipada aos consumidores e um prazo definido para desativação. Manter versões vulneráveis em produção indefinidamente porque consumidores não migraram é um risco inaceitável. O versionamento deve ser explícito na URL ou no header, nunca implícito. Cada versão descontinuada deve ter seus endpoints desabilitados, não apenas removidos da documentação. Contratos de API podem incluir cláusulas de segurança que obriguem consumidores a manterem-se em versões suportadas, transferindo parte da responsabilidade de forma contratual.

Monitoramento contínuo e testes de segurança

Segurança de API não é um ponto de checagem único, mas um processo contínuo. Ferramentas de API security gateway ou WAF especializado em APIs podem detectar padrões de ataque em tempo real. Testes automatizados de segurança devem fazer parte do pipeline de CI/CD, incluindo SAST para revisar código, DAST para testar a API em execução e testes específicos como fuzzing de parâmetros e verificação de Broken Object Level Authorization (BOLA). Penetration tests periódicos conduzidos por profissionais com conhecimento específico em APIs complementam a automação. O relatório setorial de 2024 sobre segurança de APIs [4] indica que organizações que integraram testes de segurança no ciclo de desenvolvimento apresentaram incidência significativamente menor de incidentes em produção.

Checklist resumido de segurança de APIs

A tabela abaixo consolida os pontos abordados em uma referência rápida para consultas durante o desenvolvimento e a revisão de APIs.

Perguntas frequentes sobre segurança de APIs

O que é uma shadow API e por que ela é perigosa?
Uma shadow API é um endpoint que está acessível na rede mas não consta do inventário oficial nem da documentação. Pode ser uma rota de depuração esquecida, uma versão antiga não desativada ou um endpoint criado de forma não padronizada. Ela é perigosa porque não passa por revisões de segurança, não é monitorada e pode expor dados sensíveis ou funcionalidades administrativas sem nenhum controle de acesso.

Chaves de API são suficientes para autenticar uma API pública?
Em cenários de baixo risco e integrações simples, chaves de API podem ser aceitáveis, mas elas têm limitações sérias: não permitem definir escopos finos, não expiram automaticamente e, uma vez comprometidas, qualquer requisição com a chave será aceita até que seja manualmente rotacionada. Para a maioria dos cenários produtivos, OAuth 2.0 com tokens de acesso de curta duração oferece um nível de segurança significativamente superior.

Como validar se minha API está vulnerável a Broken Object Level Authorization (BOLA)?
O teste mais direto é autenticar com um usuário legítimo e, em seguida, manipular os identificadores de recursos nas requisições para tentar acessar dados pertencentes a outros usuários ou organizações. Se a API retornar dados que não pertencem ao consumidor autenticado, há uma falha de autorização a nível de objeto. Esse teste deve ser automatizado no pipeline de CI/CD e também verificado manualmente em pentests.

Com que frequência o inventário de APIs deve ser revisado?
O inventário deve ser atualizado continuamente, com revisões formais no mínimo a cada trimestre ou sempre que houver uma release significativa. Em organizações com múltiplas equipes, é recomendável implementar descoberta automatizada de endpoints em runtime, cruzando os dados com o inventário declarado para identificar discrepâncias. A integração do inventário com a plataforma de CI/CD, onde novas APIs só podem ser implantadas se registradas no inventário, é uma prática madura de governança.

É necessário ter um WAF específico para APIs ou um WAF tradicional atende?
WAFs tradicionais foram projetados para proteger aplicações web baseadas em HTML e formulários, e têm dificuldade em entender a semântica de requisições JSON/XML, paths parametrizados e fluxos OAuth. Um API gateway com capacidades de segurança ou um WAF especializado em APIs oferece visibilidade sobre a estrutura dos payloads, detecção de BOLA, quebra de schema e anomalias específicas do tráfego de APIs. Em ambientes com volume significativo de APIs, a diferença de cobertura é considerável.

Fontes

[1] CERT.br — Fascículos da Cartilha de Segurança para Internet

[2] Governo Digital — CERT.br — Referência oficial do Governo Federal

[3] FEBRABAN — Guia de Boas Práticas de Segurança

[4] Relatório de Gestão e Segurança de APIs 2024 — Levantamento setorial sobre maturidade de segurança de APIs