Esta é a história da empresa A e da empresa B, cujas abordagens de segurança de APIs e aplicativos web, aparentemente diferentes, compartilham uma falha sutil, mas crucial. Essa falha resultou em violações de dados (e todos os resultados negativos associados) para ambas.
A empresa A tem a proteção de APIs mais segura possível. Eles bloqueiam todas as violações de esquema, limitam as taxas de solicitações excessivas e usam a inteligência contra ameaças mais recente para colocar endereços de IP maliciosos conhecidos na lista de bloqueios. Sua autenticação de APIs baseada em senha poderia ser mais segura se fosse substituída por mutual TLS, mas eles ainda não sofreram uma violação.
Entretanto, sua segurança de APIs, feed de inteligência contra ameaças e WAF são todos de fornecedores diferentes. E, devido a atualizações dos fornecedores, a inteligência contra ameaças que informa a segurança de APIs não é mais compatível com o WAF, que protege a página de login da conta. Consequentemente, um invasor é capaz de usar uma nova exploração de injeção de SQL nesta página e obter um nome e senha de um usuário legítimo. O invasor então, envia solicitações autenticadas e validadas pelo esquema para a API deles e obtém grandes volumes de dados confidenciais.
Enquanto isso, o aplicativo web da empresa B está totalmente protegido contra ataques DDoS. A empresa B também expõe uma API para usuários pagantes que desejam se integrar ao aplicativo da empresa B.
O invasor compra a chave de API de um usuário pagante legítimo na dark web. Armado com essa chave, o invasor lança um ataque DDoS baixo e lento contra o servidor de APIs da empresa B. O invasor ativa um bot que envia solicitações em intervalos irregulares. Cada solicitação de API enviada pelo bot é aceita como legítima pelo servidor de APIs, porque vem com uma chave de API aceitável. E infelizmente para a empresa B, sua equipe de back-end esqueceu de fazer proxy de seu servidor de APIs por meio de seu provedor de mitigação de DDoS, apesar de todos os outros servidores estarem protegidos.
À medida que as solicitações se acumulam, o servidor de APIs fica sobrecarregado e, finalmente, não consegue atender aos outros usuários da empresa B. Muitos deles ficam frustrados e cancelam suas contas pagas.
Que problema as empresas A e B têm em comum?
Nesses exemplos, as abordagens de segurança de APIs e aplicativos web de ambas as empresas eram combinações de soluções de vários fornecedores. As soluções não eram integradas e também propensas a erros manuais.
Para entender por que isso é um problema, considere os componentes típicos de um aplicativo web e da estrutura de segurança de APIs:
WAF: bloqueia ataques contra aplicativos web e ativos da web
Gerenciamento de bots: responsável por desafiar ou bloquear prováveis bots maliciosos
Mitigação de DDoS: mantém os ativos da web on-line diante de ataques de DDoS de qualquer tipo (sejam volumétricos ou lentos e de baixa intensidade)
Proteção de APIs: inclui limitação de taxa, validação de esquema, autenticação e outros recursos para APIs.
A empresa A e a empresa B adotaram todas essas proteções. Mas como suas soluções de segurança de aplicativos web eram diferentes (mesmo que fossem as melhores da categoria), elas apresentaram falhas que o invasor foi capaz de explorar.
Para a empresa A, tanto o WAF quanto a proteção de APIs, que são em camadas em vez de integrados, tiveram que enfrentar e bloquear o ataque. Ataques que um pode parar podem passar pelo outro. A proteção contra DDoS da empresa B não protegeu sua infraestrutura de APIs, seu gerenciamento de bots não detectou solicitações de APIs originadas de bots e sua autenticação era fraca e fácil de ser comprometida.
Estes são apenas alguns exemplos de possíveis lacunas. Outras lacunas comuns na segurança de aplicativos web incluem:
Inteligência contra ameaças limitada: inteligência contra ameaças que não está atualizada, não atua onde é necessário ou não está em um formato compatível. Isso aconteceu com a empresa A.
Inteligência contra ameaças em excesso proveniente de muitas fontes: resultando em falsos positivos, redundância e outras ineficiências.
Falsos positivos de bots: isso pode frustrar os usuários, desacelerar o serviço e levar a uma aplicação negligente.
Fadiga de alerta: um estudo do Ponemon Institute de 2025 confirma que uma empresa média implementa 45 ferramentas de segurança distintas, um reflexo de constatações anteriores, mas que ainda evidencia a proliferação de ferramentas e o aumento da fadiga de alertas. Na verdade, análises mais recentes do setor sugerem que muitas organizações agora usam de 60 a 80 soluções de segurança diferentes e algumas gerenciam até 140, aumentando ainda mais a complexidade e os encargos de gerenciamento.
Autenticação insuficiente: Tanto a empresa A quanto a empresa B eram vulneráveis a roubo de credenciais de alguma forma.
Defesa contra ameaças não escalável: os dispositivos de segurança de hardware afunilam o tráfego e ficam sobrecarregados durante grandes ataques ou com vários ataques.
Essas lacunas estão se tornando ainda mais arriscadas à medida que a complexidade e a sofisticação dos ataques cibernéticos aumentam. Segundo a McKinsey, desde o lançamento do ChatGPT, os sites de phishing detectados aumentaram 138%, impulsionados pelo papel da IA generativa na criação de e-mails e deepfakes mais convincentes, acelerando significativamente as capacidades dos atacantes.
Os atacantes modernos geralmente se movem mais rápido e aprimoram suas táticas com mais velocidade do que seus alvos.
As APIs são cada vez mais importantes para a infraestrutura de aplicativos web das organizações modernas. Hoje, uma parte significativa do tráfego dinâmico processado pela Cloudflare é baseada em APIs, e essa parcela continua aumentando. Na verdade, muitas organizações se descrevem como API-first. Além disso, a Cloudflare bloqueia uma porcentagem maior de tráfego de APIs considerado malicioso do que de tráfego da web, demonstrando que os invasores, têm as APIs claramente em sua mira.
Com APIs frequentemente incorporadas profundamente em aplicativos da web, sua segurança deve ser primordial. No entanto, equipes internas bem-intencionadas geralmente implantam APIs rapidamente e muitas vezes sem consultar a segurança. O resultado: muitas violações de aplicativos web podem ser atribuídas à baixa segurança das APIs.
Um exemplo marcante dos riscos crescentes associados a APIs inseguras vem da TotalEnergies. Em 2025, a infraestrutura de APIs com falhas levou a um impressionante aumento de 105 vezes nos dados expostos, passando de apenas 210.715 registros em 2024 para mais de 22 milhões compartilhados nos mercados da dark web. Esse salto dramático destaca a necessidade urgente de que o setor de energia, e todos os outros, tratem a segurança de APIs como infraestrutura essencial, não como algo secundário.
E se, em vez de usar uma colcha de retalhos de produtos de segurança, a empresa A e a empresa B tivessem combinado todos os seus aplicativos web e serviços de segurança de API em uma plataforma consolidada? E todos esses serviços diferentes fossem integrados entre si? E os dados sobre o estado da infraestrutura da empresa aparecessem em um único local, para que elas pudessem avaliar rapidamente os ataques e sua postura de segurança?
A empresa A poderia ter garantido que todos os seus aplicativos web e componentes da estrutura de segurança de APIs tivessem a inteligência contra ameaças mais recente e ter interrompido o ataque antes que ele começasse, já que tudo estaria em uma única plataforma. A empresa B poderia ter estendido com mais facilidade sua proteção contra DDoS a todos os seus servidores.
Usar uma plataforma significaria uma gestão mais fácil, com menos lacunas.
Essa abordagem consolidada para a segurança de aplicativos web requer uma infraestrutura altamente escalável, capaz de fazer proxy de todos os tipos de tráfego. Nas décadas anteriores, as organizações compravam aparelhos quando precisavam se defender de novos ataques ou quando precisavam escalar. Mas um serviço baseado em nuvem escala mais facilmente e deve ser capaz de fazer proxy de qualquer tipo de infraestrutura. E embora uma plataforma consolidada não seja garantia contra todos os ataques, certamente teria ajudado nossas empresas hipotéticas.
Isto não é apenas um experimento hipotético de reflexão. As plataformas WAAP (proteção de aplicativos web e APIs) estão rapidamente se tornando uma infraestrutura essencial, não apenas uma prática recomendada teórica. O mercado global de WAAP em nuvem foi avaliado em US$ 6,12 bilhões em 2023, e está projetado para crescer a uma taxa de crescimento anual composta de 17,8% até 2032, de acordo com a DataHorizzon Research.
Esse crescimento reflete a necessidade crescente de consolidar WAF, mitigação de bots, proteção contra DDoS e segurança de APIs em serviços em nuvem escaláveis, especialmente à medida que aplicativos web e APIs enfrentam um volume crescente de ameaças complexas em ambientes multinuvem.
WAAP não é apenas mais um acrônimo: consolidar WAF, gerenciamento de bots, proteção contra DDoS, segurança de APIs e outros serviços é cada vez mais essencial para as organizações modernas. A natureza global da internet expõe aplicativos web e APIs a vetores de ataque variados e cada vez mais complexos. Não é surpreendente que os custos de violação de dados continuem a aumentar. Em 2023, o custo médio global de uma violação subiu para US$4,45 milhões, com organizações dos EUA arcando com alguns dos maiores encargos financeiros, cerca de US$ 9,48 milhões por incidente. No início de 2024, esse número global cresceu ainda mais para aproximadamente US$4,88 milhões, um aumento de 10% em apenas um ano.
Se a empresa A e a empresa B desenvolvessem seus aplicativos e APIs do zero hoje, elas poderiam hospedá-los totalmente em nuvem, talvez com um provedor de hospedagem para facilitar a implantação. Mas, na realidade, a maioria das organizações implantam infraestrutura híbrida com servidores de banco de dados no local legados, APIs de terceiros baseadas em nuvem e serviços de aplicativos hospedados em várias nuvens. Essas implantações oferecem muitas vantagens, mas também apresentam seus próprios desafios de segurança.
Por exemplo, a segurança nativa na oferta de um determinado provedor de nuvem pode não se estender a toda a sua infraestrutura. Para começar, descobrir e mapear toda a sua infraestrutura para depois defendê-la também pode ser um desafio. E, por último, seus produtos de segurança podem não ser compatíveis com outras soluções em sua pilha de tecnologia.
Portanto, além de consolidar recursos essenciais de segurança de aplicativos web, o WAAP precisa ser independente de infraestrutura, o que significa que deve ser capaz de se posicionar na frente de qualquer tipo de infraestrutura ou implantação em nuvem.
A Cloudflare é nativa de nuvem e independente de infraestrutura, oferece segurança de aplicativos web há mais de uma década e oferece todos esses recursos como uma plataforma consolidada, em um único painel de controle. A Cloudflare também tem a vantagem de observar uma grande porcentagem do tráfego da internet, atendendo a mais de 78 milhões de solicitações HTTP por segundo e bloqueando ~190 bilhões de ameaças cibernéticas por dia, em média. Isso dá à Cloudflare visibilidade única sobre ameaças de dia zero e novos ataques.
Este artigo é parte de uma série sobre as tendências e os assuntos mais recentes que influenciam os tomadores de decisões de tecnologia hoje em dia.
A Gartner reconheceu a Cloudflare como líder no Gartner® Magic Quadrant™ for Web Application and API Protection (WAAP) de 2022.
Após ler este artigo, você entenderá:
Como soluções de segurança diferentes podem criar lacunas de segurança
Exemplos de como essas lacunas podem se manifestar
Por que a Gartner recomenda a consolidação em uma plataforma de segurança de aplicativos web independente de infraestrutura