Práticas recomendadas de segurança de API: autenticação, autorização e limitação de taxa

APIs são o tecido conjuntivo das plataformas de negócios modernas. Seu ERP se comunica com sua loja de comércio eletrônico por meio de APIs. Seu gateway de pagamento processa transações por meio de APIs. Seu aplicativo móvel busca dados por meio de APIs. E os invasores sabem disso: o Gartner prevê que, até 2026, as APIs serão o vetor de ataque mais frequente para aplicações web corporativas, ultrapassando as interfaces web tradicionais.

O Top 10 de segurança de API da OWASP revela que as vulnerabilidades de API mais comuns não são exóticas de dia zero – são falhas de autenticação fundamentais, autorização quebrada e exposição excessiva de dados. Estes são defeitos evitáveis ​​que resultam de uma arquitetura de segurança inadequada e não de ataques sofisticados.

Principais conclusões

• OAuth2 com PKCE é o padrão atual para autenticação de API; As chaves de API por si só são insuficientes para sistemas de produção
• Autorização em nível de objeto quebrada (BOLA) é a vulnerabilidade número um da API --- cada endpoint deve verificar a propriedade do recurso
• A limitação de taxa é um controle de segurança, não apenas uma otimização de desempenho --- ela evita preenchimento de credenciais, enumeração e DoS
• A validação de entrada no limite da API evita ataques de injeção, estouro e lógica de negócios antes que eles cheguem ao seu banco de dados

---

Autenticação: Prova de Identidade

A autenticação responde à pergunta "quem está fazendo esta solicitação?" Para APIs, a resposta deve ser verificável criptograficamente, resistente a ataques de repetição e escalável em sistemas distribuídos.

Comparação de métodos de autenticação

Práticas recomendadas de OAuth2 e OIDC

OAuth2 com OpenID Connect (OIDC) é o padrão para autenticação de API em aplicativos modernos. Principais práticas de implementação:

Use o fluxo do código de autorização com PKCE para todos os tipos de clientes, incluindo aplicativos de página única e aplicativos móveis. O fluxo implícito foi descontinuado devido à exposição do token no histórico do navegador e nos cabeçalhos de referência.

Tokens de acesso de curta duração. Os tokens de acesso devem expirar em 15 a 60 minutos. Use tokens de atualização (armazenados com segurança e alternados durante o uso) para obter novos tokens de acesso sem nova autenticação.

Armazenamento de tokens. Nunca armazene tokens em localStorage ou sessionStorage (vulnerável a XSS). Use cookies HttpOnly com atributos Secure e SameSite. Para SPAs que devem usar tokens diretamente, mantenha-os apenas na memória e aceite a compensação da perda de sessão na atualização da página.

Valide os tokens minuciosamente. Cada solicitação de API deve verificar a assinatura, a expiração, o emissor, o público e o escopo do token. Não decodifique simplesmente o JWT e confie em seu conteúdo.

Vinculação de token. Sempre que possível, vincule tokens ao cliente que os solicitou usando cabeçalhos DPoP (Demonstrando Prova de Posse) para evitar roubo e repetição de token.

Considerações de segurança JWT

JWTs são o formato de token mais comum para APIs, mas apresentam riscos específicos:

• Nunca use o algoritmo none. Sempre valide o cabeçalho alg em relação a uma lista de permissões de algoritmos esperados.
• Prefira algoritmos assimétricos (RS256, ES256) em vez de simétricos (HS256) para APIs voltadas ao público. As chaves assimétricas permitem a verificação do token sem compartilhar a chave de assinatura.
• Inclui declarações padrão: iss (emissor), aud (público), exp (expiração), iat (emitido em), sub (assunto), jti (ID exclusivo para revogação).
• Mantenha as cargas úteis pequenas. JWTs não são um banco de dados. Inclua apenas as declarações necessárias para decisões de autorização. Busque dados adicionais de endpoints de informações do usuário quando necessário.
• Implementar revogação de token. Use tempos de expiração curtos combinados com uma lista de bloqueio de token (em Redis ou similar) para revogação imediata quando contas forem comprometidas.

---

Autorização: aplicando controle de acesso

A autenticação informa quem está fazendo a solicitação. A autorização informa o que eles estão autorizados a fazer. O OWASP API Top 10 lista a autorização em nível de objeto quebrado (BOLA) como a vulnerabilidade número um da API porque é a mais comum e a mais impactante.

RBAC x ABAC

Controle de acesso baseado em função (RBAC) atribui permissões a funções e os usuários são atribuídos a funções. É simples de implementar e raciocinar.

Controle de acesso baseado em atributos (ABAC) avalia políticas em relação aos atributos do usuário, do recurso, da ação e do ambiente. Suporta regras mais complexas, mas é mais difícil de auditar.

Para a maioria das plataformas de negócios, incluindo sistemas ERP e de comércio eletrônico, o RBAC é suficiente quando combinado com verificações de propriedade de recursos. Considere o ABAC quando suas regras de autorização dependerem de fatores contextuais como hora, local, classificação de dados ou hierarquias organizacionais dinâmicas.

Prevenindo a BOLA

A autorização em nível de objeto quebrada ocorre quando uma API permite que os usuários acessem ou modifiquem recursos pertencentes a outros usuários, manipulando identificadores de recursos. Por exemplo, alterar /api/orders/12345 para /api/orders/12346 não deve revelar o pedido de outro usuário.

Regras de prevenção:

1. Cada endpoint deve verificar a propriedade dos recursos. Nunca confie apenas na autenticação. Depois de verificar a identidade do usuário, verifique se ele tem acesso ao recurso específico solicitado.
2. Use referências indiretas. Em vez de expor IDs de banco de dados sequenciais, use UUIDs ou números de referência no escopo do usuário.
3. Aplicar na camada de dados. Adicione filtros de propriedade (por exemplo, WHERE organization_id = ?) a cada consulta ao banco de dados, não apenas no nível do controlador. Este é o padrão de multilocação usado em toda a arquitetura da plataforma ECOSIRE.
4. Testes automatizados. Inclua testes de desvio de autorização em seu pipeline de CI/CD. Para cada endpoint, teste se o Usuário A não pode acessar os recursos do Usuário B.

---

Limitação e limitação de taxa

A limitação de taxa é um controle de segurança que evita abusos, não apenas uma otimização de desempenho que evita sobrecarga. Sem limitação de taxa, os invasores podem realizar o preenchimento de credenciais em milhares de tentativas por segundo, enumerar contas válidas, copiar todo o seu catálogo de produtos ou esgotar suas cotas de API com provedores upstream.

Estratégias de limitação de taxas

Limitação de taxa por tipo de endpoint

Endpoints diferentes enfrentam perfis de ameaças diferentes e exigem limites diferentes:

• Endpoints de autenticação (login, troca de token): 5 a 10 solicitações por minuto por IP. Limites baixos evitam preenchimento de credenciais e força bruta.
• Redefinição de senha/recuperação de conta: 3 a 5 solicitações por hora por conta. Impede enumeração e abuso de contas.
• Endpoints de leitura de dados: 100 a 1.000 solicitações por minuto por usuário. Evita raspagem ao mesmo tempo que permite o uso normal.
• Endpoints de gravação de dados: 30 a 60 solicitações por minuto por usuário. Evita abuso automatizado e spam.
• Endpoints de pesquisa pública: 20 a 60 solicitações por minuto por IP. Evita raspagem competitiva.
• Receptores de webhook: validam assinaturas em vez de limitar a taxa, mas descartam solicitações que excedem o volume esperado.

Implementando Limites de Taxa

Retorne códigos de status e cabeçalhos HTTP adequados para que os clientes possam se autorregular:

• 429 Muitas solicitações quando o limite é excedido
• Cabeçalho Retry-After com o número de segundos até o limite ser redefinido
• Cabeçalho X-RateLimit-Limit mostrando o total de solicitações permitidas
• Cabeçalho X-RateLimit-Remaining mostrando solicitações deixadas na janela
• Cabeçalho X-RateLimit-Reset com o carimbo de data/hora UTC quando a janela é reiniciada

Use um serviço centralizado de limitação de taxa (apoiado pelo Redis) em vez de limites por instância para evitar que invasores distribuam solicitações entre instâncias para contornar os limites.

---

Validação de entrada

A validação de entrada no limite da API é sua primeira linha de defesa contra ataques de injeção, buffer overflows e exploração de lógica de negócios. Cada dado que entra em sua API deve ser validado quanto ao tipo, formato, comprimento, intervalo e regras de negócios.

Os 10 principais segurança da API OWASP

O OWASP API Security Top 10 (edição 2023) identifica os riscos críticos que cada API deve abordar:

Melhores práticas de validação

Validação de esquema. Defina esquemas de solicitação (usando JSON Schema, Zod ou especificação OpenAPI) e rejeite qualquer solicitação que não esteja em conformidade. Isso captura dados malformados antes que cheguem à lógica de negócios.

Consultas parametrizadas. Nunca concatene a entrada do usuário em consultas SQL, NoSQL ou LDAP. Use consultas parametrizadas ou métodos ORM que lidam com o escape automaticamente. Esta é uma regra crítica de segurança para todas as plataformas de negócios.

Aplicação do tipo de conteúdo. Aceite apenas cabeçalhos de tipo de conteúdo esperados. Uma API que espera JSON deve rejeitar XML, dados de formulário e outros tipos de conteúdo para evitar ataques baseados em analisador.

Filtragem de resposta. Nunca retorne registros completos do banco de dados ao cliente. Use DTOs (Data Transfer Objects) para definir explicitamente quais campos serão incluídos em cada resposta. Campos internos como hashes de senha, IDs internos e metadados de auditoria nunca devem aparecer nas respostas da API.

Tratamento de erros. Retorna mensagens de erro genéricas aos clientes. Nunca exponha rastreamentos de pilha, erros de banco de dados ou detalhes internos do sistema. Registrar erros detalhados no lado do servidor para depuração.

---

Padrões de arquitetura de segurança de API

Padrão de gateway de API

Um gateway de API fica na frente de todos os serviços de back-end e centraliza questões transversais de segurança:

• Autenticação --- Valida tokens antes que as solicitações cheguem aos serviços de back-end
• Limitação de taxa --- Impõe limites no nível do gateway
• Transformação de solicitação/resposta --- Remove cabeçalhos confidenciais e adiciona cabeçalhos de segurança
• Registro e monitoramento --- Captura todo o tráfego da API para análise de segurança
• Integração WAF --- Bloqueia padrões de ataque conhecidos (injeção de SQL, cargas XSS)

Gateways de API populares incluem Kong, AWS API Gateway, Azure API Management e Traefik.

Autenticação serviço a serviço

APIs internas entre microsserviços também exigem autenticação. As opções incluem:

• TLS mútuo (mTLS) --- Tanto o cliente quanto o servidor apresentam certificados. Forte, mas operacionalmente complexo.
• Tokens de serviço --- Os serviços são autenticados com tokens pré-compartilhados. Simples, mas requer distribuição segura.
• Service mesh --- Istio ou Linkerd lidam com mTLS automaticamente entre serviços no Kubernetes.
• Credenciais do cliente OAuth2 --- Os serviços são autenticados usando ID do cliente e segredo para obter tokens de acesso.

Para arquitetura de confiança zero, a autenticação serviço a serviço é essencial para evitar movimentos laterais após uma violação.

---

Monitoramento e detecção de incidentes

O monitoramento de segurança da API deve capturar tanto sinais técnicos (tentativas de autenticação malsucedidas, padrões de solicitação incomuns) quanto sinais comerciais (valores de transações anômalas, acesso a dados em massa).

Sinais críticos de segurança da API

• Falhas de autenticação --- Aumento de logins com falha de um único IP ou visando uma única conta
• Falhas de autorização --- 403 respostas indicando usuários tentando acessar recursos não autorizados
• Violações de limite de taxa --- 429 respostas sustentadas da mesma fonte
• Volumes de dados incomuns --- Operações de leitura em massa que sugerem exfiltração de dados
• Adulteração de parâmetros --- Enumeração de ID sequencial, valores negativos, teste de limite
• Anomalias geográficas --- Chamadas de API de regiões inesperadas ou padrões de viagem impossíveis

Crie painéis que mostrem esses sinais em tempo real. Integre-se ao seu SIEM para correlação com outros eventos de segurança. Defina respostas automatizadas para ameaças de alta confiança: bloqueie IPs que excedam os limites de autenticação com falha, desative temporariamente contas que apresentem viagens impossíveis e alerte sobre padrões de acesso a dados em massa.

---

Perguntas frequentes

Devo usar chaves de API ou tokens OAuth2?

Use tokens OAuth2 para qualquer API que atenda aplicativos voltados para o usuário ou integrações de terceiros. As chaves de API são aceitáveis ​​apenas para comunicação entre servidores, onde ambos os endpoints estão sob seu controle e, mesmo assim, as solicitações assinadas por HMAC fornecem segurança mais forte. Nunca use chaves de API como única autenticação para endpoints acessíveis publicamente.

Como lidar com o versionamento de API com segurança?

Use controle de versão baseado em URL (por exemplo, /api/v2/orders) para maior clareza e descoberta. Ao descontinuar uma versão, defina uma data de expiração, comunique-a aos consumidores e monitore o uso. Continue aplicando patches de segurança às versões obsoletas até que sejam totalmente descontinuadas. Nunca deixe versões antigas da API sem correção em execução – elas se tornam alvos fáceis.

Quais limites de taxa devo definir para uma API empresarial?

Comece de forma conservadora e aumente com base em dados de uso legítimos. Para endpoints de autenticação, o padrão é de 5 a 10 solicitações por minuto por IP. Para endpoints de dados, 100 a 500 solicitações por minuto por usuário autenticado cobrem a maioria dos casos de uso de negócios. Monitore as respostas 429 para identificar limites que sejam muito restritivos e monitore padrões de abuso para identificar limites que sejam muito generosos.

Como posso proteger webhooks de serviços de terceiros?

Verifique assinaturas de webhook usando HMAC-SHA256 com um segredo compartilhado. Valide o carimbo de data/hora para evitar ataques de repetição (rejeite eventos com mais de 5 minutos). Processe webhooks de forma assíncrona para evitar negação de serviço baseada em tempo limite. Registrar todos os eventos de webhook para fins de auditoria. Valide o esquema de carga útil antes do processamento.

---

O que vem a seguir

A segurança da API não é um recurso que você adiciona no final do desenvolvimento – é um princípio de design que deve estar presente desde o primeiro endpoint. Comece com autenticação forte (OAuth2/OIDC), aplique autorização em cada ponto de acesso de recursos, implemente limitação de taxa em todos os tipos de endpoint e valide cada entrada que cruze os limites da API.

ECOSIRE incorpora segurança em cada integração de API. Nossa plataforma OpenClaw AI implementa solicitações assinadas por HMAC, limitação de taxa e proteção SSRF por padrão, enquanto nossas integrações Odoo ERP usam OAuth2/OIDC com controle de acesso baseado em função. Entre em contato com nossa equipe para proteger as APIs da sua plataforma de negócios.

---

Publicado por ECOSIRE --- ajudando empresas a escalar com soluções baseadas em IA em Odoo ERP, Shopify eCommerce e OpenClaw AI.