Tradicionalmente, a segurança funciona como um jogo de defesa. Nesse modelo, as organizações constroem barreiras, instalam portões e criam regras para bloquear tráfego suspeito. Há anos, a Cloudflare lidera este segmento: nossa plataforma de Segurança de Aplicativos foi projetada para detectar ataques em andamento e descartar solicitações maliciosas na borda da rede antes mesmo que elas cheguem ao servidor de origem.
No entanto, quando falamos de segurança de APIs, apenas uma postura defensiva já não é suficiente.
Por esse motivo, estamos lançando hoje a versão beta do Web and API Vulnerability Scanner da Cloudflare.
- Leia também: WordPress lança Assistente de IA integrado para criação e edição de sites
- Leia também: WhatsApp pode permitir fixar até 20 conversas na versão paga do aplicativo
- Leia também: Governança de IA corporativa: como avaliar ferramentas de controle de uso de inteligência artificial
Inicialmente, começaremos abordando uma das ameaças mais disseminadas e difíceis de detectar no OWASP API Top 10: Autorização em Nível de Objeto Quebrada (BOLA). Com o tempo, adicionaremos novos tipos de varredura de vulnerabilidades, incluindo ameaças tanto para APIs quanto para aplicações web.
Hoje em dia, as vulnerabilidades de API mais perigosas não são ataques genéricos de injeção ou requisições malformadas que um WAF consegue detectar facilmente. Em vez disso, tratam-se de falhas lógicas: requisições HTTP perfeitamente válidas que seguem as especificações do protocolo e da aplicação, mas que acabam contrariando a lógica de negócios.
Por isso, para encontrá-las, não basta esperar que um ataque aconteça. É necessário procurá-las ativamente.
O Web and API Vulnerability Scanner estará disponível inicialmente para clientes do API Shield. A seguir, explicamos por que estamos focando nas varreduras de segurança de API nesta primeira versão.
Por que a segurança puramente defensiva não é suficiente
No mundo das aplicações web, muitas vulnerabilidades aparecem como erros de sintaxe.
Por exemplo:
- Uma tentativa de injeção de SQL aparece como código inserido onde deveriam existir apenas dados.
- Um ataque de cross-site scripting (XSS) surge como uma tag de script em um campo de formulário.
Esses ataques possuem assinaturas claras, o que facilita sua identificação.
Entretanto, as vulnerabilidades de API funcionam de forma diferente.
Para ilustrar, imagine um aplicativo móvel de entrega de comida que se comunica exclusivamente com uma API no backend. Vamos considerar o endpoint de pedidos:
Definição do endpoint: /api/v1/orders
| Método | Caminho do recurso | Descrição |
| GET | /api/v1/orders/{order_id} | Verifica o status do pedido e retorna informações de rastreamento (ex.: “A cozinha está preparando”). |
| PATCH | /api/v1/orders/{order_id} | Atualiza o pedido, permitindo alterar o local de entrega ou adicionar instruções. |
Agora imagine um cenário de autorização quebrada, como ocorreu no ataque BOLA.
Nesse caso, o usuário A (atacante) tenta atualizar o endereço de entrega de um pedido que pertence ao usuário B (vítima). Para isso, basta inserir o {order_id} do usuário B dentro da requisição PATCH.
Por exemplo, suponha que o ID do pedido do Usuário B seja 8821.
Nesse cenário:
- Os cabeçalhos da requisição são válidos
- O token de autenticação é legítimo
- O formato da requisição está correto
Portanto, para um WAF tradicional, essa requisição parece completamente normal. Inclusive, uma solução de gerenciamento de bots pode ser enganada caso um humano esteja enviando manualmente as requisições maliciosas.
Como resultado, o usuário A poderia receber em casa a comida do usuário B.
Essa vulnerabilidade ocorre porque o endpoint de API não valida se o usuário autenticado realmente tem permissão para acessar ou modificar aquele recurso.
Ou seja, trata-se de uma falha de lógica, não de sintaxe.
Para corrigir o problema, o desenvolvedor poderia implementar uma verificação simples como:
if (order.userID != user.ID) throw Unauthorized;
Como detectar esse tipo de vulnerabilidade
Existem duas formas principais de identificar essas falhas:
- Enviando tráfego de teste para a API
- Monitorando passivamente o tráfego existente
A detecção passiva exige um contexto detalhado sobre o comportamento da API.
No ano passado, lançamos a detecção de vulnerabilidades BOLA no API Shield, que analisa automaticamente o tráfego do cliente em busca de anomalias.
Para que esse método funcione bem, é necessário entender:
- Como é uma chamada de API considerada “válida”
- Quais parâmetros variam entre requisições
- Como os usuários normalmente interagem com a API
- Como a API reage quando esses parâmetros são manipulados
Contudo, existem situações em que as equipes de segurança não possuem esse contexto.
Por exemplo:
- Ambientes de desenvolvimento podem não ter tráfego de usuários
- Ambientes de produção podem não apresentar ataques ainda
- APIs novas podem ainda não ter padrões claros de uso
Nesses casos, as equipes recorrem ao Teste Dinâmico de Segurança de Aplicativos (DAST).
Ferramentas DAST criam perfis de tráfego específicos para testes de segurança, permitindo procurar vulnerabilidades em qualquer ambiente e a qualquer momento.
No entanto, ferramentas DAST tradicionais apresentam alguns problemas importantes:
- São complexas de configurar
- Exigem upload manual de arquivos Swagger/OpenAPI
- Têm dificuldade para autenticar fluxos modernos de login
- Muitas vezes não incluem testes específicos para APIs, como o BOLA
A vantagem da análise de API da Cloudflare
No exemplo do aplicativo de entrega, assumimos que o atacante poderia encontrar um pedido válido para modificar. Em ambientes reais, isso pode acontecer por diversos meios.
Entretanto, em um teste de segurança, é necessário criar os próprios objetos antes de testar as permissões da API.
Esse processo costuma ser complicado para scanners DAST tradicionais, pois muitos deles tratam cada requisição individualmente. Dessa forma, eles não conseguem encarar as chamadas no padrão lógico necessário para identificar vulnerabilidades de autorização.
Além disso, scanners DAST legados frequentemente funcionam como ferramentas isoladas, sem integração com outros sistemas de segurança.
A abordagem da Cloudflare é diferente.
Primeiro, o Security Insights apresentará os resultados dessas novas verificações juntamente com outras descobertas de segurança da Cloudflare. Assim, você terá toda a visibilidade de segurança em um único painel.
Em segundo lugar, já conhecemos as entradas e saídas da sua API. Se você utiliza o API Shield, a Cloudflare já possui informações sobre sua API por meio dos recursos de:
- Descoberta de API
- Aprendizado de Esquema
Esses sistemas catalogam endpoints automaticamente e aprendem padrões de tráfego.
Embora a primeira versão exija o upload manual de uma especificação OpenAPI, futuramente será possível iniciar a análise sem precisar fornecer esse arquivo.
Além disso, como estamos posicionados na borda da rede, conseguimos transformar a inspeção passiva de tráfego em inteligência ativa. Isso significa que o scanner pode validar automaticamente vulnerabilidades BOLA enviando novas requisições HTTP.
Por fim, desenvolvemos uma nova plataforma DAST com o estado. Diferente de scanners tradicionais, que exigem horas de configuração, nossa solução permite iniciar rapidamente:
- Você fornece as credenciais da API
- Nós utilizamos os esquemas da API
- O sistema cria automaticamente um plano de varredura
Construindo planos de varredura automaticamente
As APIs geralmente são documentadas usando esquemas OpenAPI. Esses documentos descrevem:
- Host
- Método
- Caminho do endpoint
- Parâmetros esperados
- Estrutura das respostas
Nosso scanner cria um grafo de chamadas de API a partir do documento OpenAPI e percorre esse grafo utilizando dois contextos diferentes:
- Proprietário do recurso
- Atacante
Primeiro, o proprietário cria recursos na API. Em seguida, o atacante tenta acessar esses recursos utilizando credenciais válidas próprias.
Se o atacante conseguir ler, modificar ou excluir um recurso que não lhe pertence, o sistema detecta automaticamente uma vulnerabilidade de autorização.
Inteligência artificial para entender APIs
Modelar automaticamente relações entre endpoints pode ser complicado. Muitas especificações OpenAPI apresentam:
- Dados incompletos
- Nomes ambíguos
- Estruturas inconsistentes
Para resolver esse problema, nosso scanner utiliza a plataforma Workers AI da Cloudflare.
Modelos avançados, como o gpt-oss-120b, conseguem identificar dependências de dados entre chamadas de API e gerar dados falsos realistas quando necessário.
Dessa forma, o sistema cria automaticamente uma representação do grafo de chamadas da API e executa os testes usando credenciais de atacante e proprietário.
Além disso, como o Workers AI roda na infraestrutura da Cloudflare, o sistema se beneficia da arquitetura global e altamente disponível da plataforma.
Construído sobre infraestrutura comprovada
Para garantir segurança e confiabilidade, o scanner utiliza serviços já consolidados na infraestrutura da Cloudflare.
O plano de controle integra-se ao Temporal, utilizado internamente para orquestração de processos complexos.
Todo o backend foi desenvolvido em Rust, linguagem amplamente utilizada pela Cloudflare para serviços de infraestrutura.
Isso permite:
- reutilizar bibliotecas internas
- manter padrões arquitetônicos consistentes
- facilitar futuras integrações com sistemas como FL2 e Flamingo
Proteção de credenciais com HashiCorp Vault
A detecção de vulnerabilidades de autenticação exige o gerenciamento de credenciais de usuários da API, e a Cloudflare trata essa responsabilidade com extremo cuidado.
Para isso, utilizamos o Vault Transit Secret Engine (TSE) da HashiCorp.
Assim que o cliente envia as credenciais, elas são imediatamente criptografadas pelo TSE. O serviço executa a criptografia, mas não armazena o texto cifrado.
Além disso:
- A API pública não possui permissão para descriptografar os dados
- A descriptografia ocorre apenas na última etapa, durante a execução do teste
- Somente o Worker responsável pela verificação pode solicitar essa operação
Também aplicamos rotação periódica de credenciais e criptografia, reduzindo ainda mais os riscos de exposição.
O que vem a seguir
Hoje estamos lançando a verificação de vulnerabilidades BOLA em versão Beta aberta para clientes do API Shield.
Por meio da API da Cloudflare, será possível:
- iniciar varreduras
- gerenciar configurações
- acessar resultados programaticamente
Isso permite integrar o scanner diretamente aos pipelines de CI/CD ou painéis de segurança.
Escolhemos começar com o BOLA porque essas vulnerabilidades:
- são difíceis de detectar
- representam alto risco para APIs modernas
No entanto, o mecanismo foi projetado para ser extensível.
Em breve, planejamos incluir também as vulnerabilidades do OWASP Web Top 10, como:
- SQL Injection (SQLi)
- Cross-Site Scripting (XSS)
A nuvem de conectividade da Cloudflare protege redes corporativas inteiras, ajuda clientes a criar aplicações em escala global, acelera sites e aplicativos, impede ataques DDoS, bloqueia invasores e ainda auxilia empresas na jornada rumo ao Zero Trust.
Você também pode acessar 1.1.1.1 em qualquer dispositivo para usar nosso aplicativo gratuito que torna sua internet mais rápida e segura.
Para saber mais sobre nossa missão de ajudar a construir uma internet melhor, comece aqui.
E se você busca uma nova oportunidade profissional, confira também nossas vagas abertas.
