No cenário de 2026, as APIs não são apenas componentes de software; elas são a espinha dorsal da economia digital e da Inteligência Artificial Agente. Como especialista em Application Security, observo que a superfície de ataque evoluiu de simples falhas técnicas para vulnerabilidades sistêmicas e de design. Este guia atualizado reflete o consenso mais recente do OWASP API Security Top 10, integrando as novas categorias do OWASP Top 10:2025/2026 e focando em exemplos práticos de laboratório.
Não focaremos muito a fundo nesse artigo sobre cada item porém você pode pesquisar cada categoria e realizar testes.
É importante notar que o OWASP API Security Top 10 teve sua última atualização em 2023. No entanto, o OWASP Top 10 geral foi atualizado para 2025/2026, introduzindo novas categorias que são altamente relevantes para a segurança de APIs. Este artigo visa conectar essas duas perspectivas, oferecendo uma visão abrangente dos riscos mais críticos e das estratégias de hardening e auditoria ética necessárias para proteger APIs no ambiente atual.
1. API1: Broken Object Level Authorization (BOLA) – A Ameaça Persistente
O BOLA continua sendo o risco número um para APIs. Em 2026, com a proliferação de APIs que alimentam modelos de linguagem (LLMs) e microsserviços, a manipulação de IDs tornou-se ainda mais crítica. A falha ocorre quando uma API expõe um endpoint que lida com identificadores de objetos (como IDs de usuários, documentos ou transações), mas não valida adequadamente se o usuário autenticado tem permissão para acessar aquele objeto específico.
| Aspecto | Exemplo Aprofundado de Laboratório (ex: OWASP crAPI) |
| Identificação | Utilize um proxy de interceptação (como Burp Suite ou OWASP ZAP) para capturar requisições a endpoints que utilizam IDs no caminho (GET /api/v1/users/123), no corpo da requisição (POST /api/v1/orders, com {“order_id”: “uuid-abc”}), ou em parâmetros de query (GET /api/v1/documents?id=doc456). Observe se os IDs são sequenciais, previsíveis (UUIDs são melhores, mas não garantem segurança sem validação) ou facilmente enumeráveis. Tente alterar o ID para um valor adjacente ou aleatório. |
| Exploração Ética | Após identificar um endpoint vulnerável, autentique-se como um usuário A. Capture uma requisição que acessa um recurso pertencente a A. Modifique o ID do recurso para um que você suspeita pertencer a um usuário B. Se a API retornar os dados do usuário B sem erro de autorização (ex: status 200 OK ou 200 Partial Content), a vulnerabilidade BOLA está confirmada. Em cenários mais avançados, tente modificar IDs em requisições PUT ou DELETE para alterar ou apagar recursos de outros usuários. |
| Hardening | Implemente ABAC (Attribute-Based Access Control) ou RBAC (Role-Based Access Control) rigoroso. Cada requisição que acessa um recurso deve validar não apenas a autenticação do usuário, mas também se ele é o proprietário ou tem permissão explícita para acessar aquele objeto. Utilize UUIDs para dificultar a enumeração, mas não confie neles como única medida de segurança. |
2. API2: Broken Authentication & Agentic AI Failures
Mecanismos de autenticação mal implementados continuam sendo um vetor de ataque crítico. Em 2026, a autenticação em APIs enfrenta o desafio adicional dos Agentes de IA, onde tokens de longa duração e chaves de API expostas em prompts de sistema ou configurações de agentes podem ser comprometidos. Falhas incluem a falta de rate limiting em endpoints de login, tokens JWT sem validação de assinatura ou expiração adequada, e o uso de credenciais fracas
| Aspecto | Exemplo Aprofundado de Laboratório |
| Identificação | Rate Limiting: Tente múltiplas tentativas de login com senhas inválidas em um curto período. Se a API não bloquear o IP ou o usuário após um número razoável de tentativas, há uma falha. Tokens: Capture um token JWT e verifique sua estrutura (ex: jwt.io). Observe se o algoritmo é None (sem assinatura), se a expiração (exp) é muito longa ou inexistente, ou se o token pode ser modificado e ainda aceito. |
| Exploração Ética | Realize um ataque de Credential Stuffing (tentar credenciais vazadas de outros sites) ou Brute Force em endpoints de login sem rate limiting. Para JWTs, se a assinatura for fraca ou ausente, tente modificar o payload (ex: alterar “role”: “user” para “role”: “admin”) e reenviar o token. Se a API aceitar, a autenticação está comprometida. |
| Hardening | Implemente Rate Limiting Adaptativo e MFA (Multi-Factor Authentication). Utilize tokens de acesso de curta duração e tokens de refresh de uso único. Garanta que todos os JWTs sejam assinados com algoritmos fortes e validados em cada requisição. Monitore tentativas de login falhas e anomalias. |
3. API3: Broken Object Property Level Authorization
Esta categoria, que combina a antiga “Excessive Data Exposure” e “Mass Assignment”, foca na granularidade das propriedades de um objeto. Ocorre quando a API retorna mais dados do que o necessário ou permite que o usuário altere propriedades que deveriam ser restritas (ex: um campo isAdmin ou credit_limit).
| Aspecto | Exemplo Aprofundado de Laboratório |
| Identificação | Exposição de Dados: Analise as respostas JSON de requisições GET a recursos de usuário (ex: GET /api/v1/profile/me). Procure por campos sensíveis que não deveriam ser expostos ao cliente (ex: password_hash, internal_id, SSN, API_KEY). Mass Assignment: Em requisições PUT ou PATCH para atualizar um recurso (ex: PUT /api/v1/profile/me), observe o payload. Tente adicionar campos que não são esperados ou que deveriam ser somente leitura (ex: {“username”: “newuser”, “is_admin”: true}). |
| Exploração Ética | Para Exposição de Dados, a simples observação já é a exploração. Para Mass Assignment, envie uma requisição PUT ou PATCH com um payload modificado, incluindo uma propriedade de privilégio (ex: “role”: “admin” ou “account_balance”: 1000000). Se a API processar e persistir essa alteração, o ataque foi bem-sucedido. |
| Hardening | Utilize DTOs (Data Transfer Objects) ou Schemas de Validação para controlar explicitamente quais campos podem ser lidos e quais podem ser escritos. Nunca confie cegamente no input do cliente. Implemente validação rigorosa no lado do servidor para todas as propriedades de objetos. |
4. API4: Unrestricted Resource Consumption (DoS & AI Costs)
Sem limites de consumo, um atacante pode sobrecarregar a infraestrutura da API, causando negação de serviço (DoS) ou custos operacionais exorbitantes. Em 2026, o foco se expande para o custo financeiro de APIs que consomem recursos caros, como tokens de IA, armazenamento em nuvem ou serviços de terceiros pagos por uso (SMS/Email) .
| Aspecto | Exemplo Aprofundado de Laboratório |
| Identificação | Verifique endpoints que aceitam parâmetros de paginação (limit, offset), upload de arquivos, ou que disparam operações custosas (ex: geração de relatórios complexos, chamadas a LLMs). Observe a ausência de limites máximos para limit ou tamanho de arquivo. |
| Exploração Ética | DoS: Envie requisições com ?limit=999999 para endpoints de listagem, ou faça upload de arquivos com tamanhos excessivos. Custos: Em APIs que disparam SMS/e-mails, automatize o envio de milhares de mensagens. Em APIs de IA, envie prompts longos e complexos em um loop, monitorando o consumo de recursos e o tempo de resposta. |
| Hardening | Implemente Rate Limiting e Throttling em todos os endpoints. Defina limites máximos para parâmetros de query (ex: limit não pode ser maior que 100). Valide o tamanho de uploads. Utilize circuit breakers e bulkheads para isolar falhas e proteger recursos críticos. |
5. API5: Broken Function Level Authorization (BFLA)
Semelhante ao BOLA, mas focado em funções ou operações. Ocorre quando um usuário comum consegue acessar endpoints administrativos ou funções privilegiadas (ex: /api/admin/delete_user) apenas por conhecer a URL, sem que a API valide seu nível de permissão para executar aquela ação .
| Aspecto | Exemplo Aprofundado de Laboratório |
| Identificação | Mapeie todos os endpoints da API, identificando aqueles que parecem ser administrativos ou de alto privilégio (ex: /admin, /manage, /settings, /users/{id}/delete). Autentique-se como um usuário com privilégios mínimos e tente acessar esses endpoints. |
| Exploração Ética | Com um token de usuário comum, tente acessar GET /api/admin/users ou POST /api/admin/promote_user. Se a API retornar dados ou executar a ação, a BFLA está presente. Tente também alterar o verbo HTTP (ex: de GET para DELETE) em endpoints de recursos para ver se a autorização funcional é verificada para cada método. |
| Hardening | Implemente RBAC (Role-Based Access Control) ou ABAC para todas as funções. Cada endpoint deve ter uma lista explícita de roles ou atributos necessários para acessá-lo. Teste rigorosamente a autorização em todos os níveis e métodos HTTP. |
6. API6: Unrestricted Access to Sensitive Business Flows
Esta falha não é necessariamente um bug de código, mas uma falha no design da lógica de negócio. Permite que processos sensíveis sejam automatizados para prejudicar o negócio (ex: bots comprando todos os ingressos de um evento, spam em formulários, abuso de cupons de desconto) .
| Aspecto | Exemplo Aprofundado de Laboratório |
| Identificação | Identifique fluxos de negócio críticos que, se abusados, podem causar prejuízo financeiro ou reputacional (ex: registro de novos usuários, compra de produtos, resgate de promoções, envio de mensagens). Verifique a ausência de mecanismos anti-bot ou validações de comportamento. |
| Exploração Ética | Crie um script para automatizar um fluxo sensível (ex: registrar 1000 contas em 1 minuto, adicionar 5000 itens ao carrinho, resgatar o mesmo cupom várias vezes). Monitore se a API impõe fricção (CAPTCHA, análise de comportamento, limites de transação) ou se permite o abuso. |
| Hardening | Implemente soluções anti-bot (ex: CAPTCHA invisível, análise de comportamento do usuário, detecção de anomalias). Adicione fricção intencional em fluxos críticos. Monitore padrões de uso incomuns e utilize Machine Learning para detectar atividades fraudulentas. |
7. API7: Server Side Request Forgery (SSRF) – O Perigo das Integrações
Ocorre quando a API recebe uma URL fornecida pelo usuário e tenta buscar o recurso sem validação adequada. Com o aumento de webhooks, integrações cloud e microsserviços, o SSRF tornou-se mais letal, permitindo que um atacante escaneie a rede interna, acesse metadados de instâncias de nuvem ou interaja com serviços internos .
| Aspecto | Exemplo Aprofundado de Laboratório |
| Identificação | Procure por parâmetros em requisições que aceitam URLs (ex: ?url=, ?image_url=, ?webhook=, ?callback=). Teste se a API tenta resolver essas URLs. |
| Exploração Ética | Forneça URLs para recursos internos da rede (ex: http://localhost:8080, http://127.0.0.1/admin), metadados de provedores de nuvem (ex: http://169.254.169.254/latest/meta-data/ para AWS EC2), ou serviços internos (ex: http://localhost:6379 para Redis, http://localhost:27017 para MongoDB). Observe as respostas da API para vazamento de informações ou interações inesperadas. |
| Hardening | Implemente uma whitelist rigorosa de URLs e protocolos permitidos. Nunca permita que a API resolva URLs fornecidas pelo usuário sem validação. Utilize bibliotecas ou funções que resolvam URLs de forma segura, bloqueando IPs privados e endereços de loopback. |
8. API8: Security Misconfiguration (O Grande Salto de 2026)
Esta categoria subiu para o Top 2 no ranking geral do OWASP Top 10:2025/2026, destacando a importância crítica das configurações seguras. APIs mal configuradas em ambientes complexos como Kubernetes, Serverless, ou com CI/CD inseguro, são um alvo fácil. Inclui desde mensagens de erro detalhadas demais até a falta de headers de segurança (HSTS, CSP) ou o uso de verbos HTTP desnecessários (como TRACE) [2].
| Aspecto | Exemplo Aprofundado de Laboratório |
| Identificação | Headers: Use curl -I <api_url> ou ferramentas de scan de segurança para verificar a presença de headers de segurança (ex: Strict-Transport-Security, X-Content-Type-Options, Content-Security-Policy). Verbos HTTP: Tente requisições OPTIONS <api_url> para listar os verbos permitidos. Se TRACE, PUT ou DELETE estiverem habilitados sem necessidade, é uma misconfiguration. Mensagens de Erro: Force erros (ex: GET /nonexistent_endpoint) e observe se as mensagens de erro revelam stack traces, versões de software ou caminhos de arquivo. |
| Exploração Ética | Explore mensagens de erro detalhadas para obter informações sobre a infraestrutura (ex: tipo de banco de dados, versão do framework). Se o método TRACE estiver habilitado, tente um ataque de Cross-Site Tracing. Se PUT estiver habilitado em um diretório, tente fazer upload de um arquivo malicioso. Procure por segredos expostos em arquivos .env acessíveis publicamente (ex: GET /static/.env). |
| Hardening | Implemente uma política de segurança por design para todas as configurações. Utilize IaC (Infrastructure as Code) para garantir configurações consistentes e seguras. Remova verbos HTTP desnecessários. Configure headers de segurança. Desabilite mensagens de erro detalhadas em produção. Realize auditorias de configuração regulares. |
9. API9: Improper Inventory Management (Shadow & Zombie APIs)
O “API Sprawl” é um desafio crescente. Versões antigas (/v1/), ambientes de staging ou endpoints de debug esquecidos (/debug, /test) frequentemente têm menos segurança que a produção e podem ser explorados. A falta de um inventário preciso e atualizado de todas as APIs expostas é uma falha crítica .
| Aspecto | Exemplo Aprofundado de Laboratório |
| Identificação | Use ferramentas de enumeração de diretórios (ex: dirb, gobuster) e subdomínios (ex: subfinder) para encontrar endpoints não documentados ou versões depreciadas (ex: dev.api.empresa.com, /api/v0/users, /api/test/data). Verifique logs de acesso para identificar APIs que não estão mais em uso, mas ainda respondem. |
| Exploração Ética | Se uma vulnerabilidade foi corrigida na versão atual da API (/v3/), tente explorá-la na versão antiga (/v1/) que pode ter sido deixada ativa por “compatibilidade” ou esquecimento. Acesse endpoints de debug para vazar informações sensíveis ou executar comandos. |
| Hardening | Mantenha um inventário completo e atualizado de todas as APIs, incluindo versões, ambientes e proprietários. Implemente um processo de desativação de APIs rigoroso. Utilize ferramentas de API Discovery para identificar Shadow e Zombie APIs. Integre a gestão de inventário ao pipeline de CI/CD. |
10. API10: Mishandling of Exceptional Conditions (A Nova Categoria de 2026)
Esta é uma nova categoria no OWASP Top 10:2025/2026, focada em como a API reage a erros e condições excepcionais. Falhas no tratamento de erros podem levar a vazamento de informações sensíveis, negação de serviço ou até mesmo bypass de controles de segurança. A complexidade dos sistemas distribuídos torna o tratamento de erros uma superfície de ataque crítica [2].
| Aspecto | Exemplo Aprofundado de Laboratório |
| Identificação | Envie inputs malformados, tipos de dados errados (ex: string onde espera um inteiro), caracteres especiais ou payloads excessivamente grandes para endpoints da API. Observe as respostas de erro (códigos HTTP, mensagens, conteúdo). |
| Exploração Ética | Vazamento de Informações: Force a API a gerar um erro que revele stack traces, mensagens de erro do banco de dados, ou informações de configuração. Bypass de Segurança: Em alguns casos, um erro não tratado pode levar a um estado de “fail open”, onde a API ignora uma etapa de validação ou autenticação e permite o acesso ao recurso. Por exemplo, um erro na validação de um token pode fazer com que a API trate a requisição como não autenticada, mas ainda assim processe parte dela. |
| Hardening | Implemente um tratamento de erros centralizado e padronizado. Nunca exponha detalhes internos de erros em produção. Utilize códigos de status HTTP apropriados. Garanta que a API sempre “fail closed” (falhe de forma segura), negando acesso em caso de erro inesperado, em vez de “fail open”. |
Novos Desafios e Tendências (2025-2026)
O futuro da segurança de APIs está intrinsecamente ligado à Inteligência Artificial e à proliferação de Agentes de IA. Os novos desafios e tendências para 2025-2026 incluem:
- Software Supply Chain Failures (A03:2025): APIs que dependem de bibliotecas de terceiros comprometidas ou de pipelines de CI/CD inseguros. O hardening agora exige SBOM (Software Bill of Materials) para APIs, varredura de dependências e validação da integridade da cadeia de suprimentos de software [2].
- AI Injection & Prompt Leakage: APIs que servem como interface para LLMs ou outros modelos de IA podem sofrer injeções que forçam a API a revelar chaves de sistema, dados de outros usuários, ou a executar ações não intencionais. A validação de inputs para LLMs é um novo campo crítico de segurança.
- Machine-to-Machine (M2M) Security: Com a arquitetura de microsserviços e a comunicação entre agentes de IA, a necessidade de identidades de máquina fortes, autorização dinâmica e gerenciamento de segredos para fluxos automatizados é primordial.
- API Discovery e Governança: A crescente complexidade e o número de APIs exigem ferramentas avançadas de descoberta e governança para identificar e proteger todas as APIs, incluindo as Shadow e Zombie APIs.
- Segurança Comportamental: A detecção de anomalias e padrões de uso incomuns, impulsionada por IA e Machine Learning, torna-se essencial para identificar ataques de lógica de negócio e abusos de recursos que não são detectados por validações estáticas.
Para validar as vulnerabilidades de forma ética desenvolvi um script em python3 para identificar as principais vulnerabilidades com uso consciente.
https://github.com/geovanidps/-api_audit_tool.git
Obs:Isenção de responsabilidade, uso apenas para fins educacionais, não me responsabilizou por uso individual.
Referências
OWASP Top 10:2025. Disponível em: https://owasp.org/Top10/2025/en/
Como especialistas, nosso papel é garantir que a segurança seja um facilitador, e não um gargalo. O Hardening de APIs exige uma combinação de validação rigorosa de esquemas, autorização granular e observabilidade contínua, tudo isso integrado a um ciclo de vida de desenvolvimento seguro (DevSecOps). A proatividade na identificação e mitigação desses riscos é a chave para proteger o futuro digital.
By: Prof.:Geovane da Costa Oliveira
