{"id":1227,"date":"2026-06-23T16:48:43","date_gmt":"2026-06-23T19:48:43","guid":{"rendered":"https:\/\/jrtx.com.br\/blog\/2026\/06\/23\/cloudflare-waf-workers-protecao-avancada-com-execucao-na-edg\/"},"modified":"2026-06-23T16:48:43","modified_gmt":"2026-06-23T19:48:43","slug":"cloudflare-waf-workers-protecao-avancada-com-execucao-na-edg","status":"publish","type":"post","link":"https:\/\/jrtx.com.br\/blog\/2026\/06\/23\/cloudflare-waf-workers-protecao-avancada-com-execucao-na-edg\/","title":{"rendered":"Cloudflare WAF Workers: Prote\u00e7\u00e3o Avan\u00e7ada com Execu\u00e7\u00e3o na Edge"},"content":{"rendered":"

\nO cen\u00e1rio de amea\u00e7as digitais em 2026 atingiu um patamar de sofistica\u00e7\u00e3o sem precedentes. Diariamente, empresas enfrentam ataques de inje\u00e7\u00e3o de comandos, explora\u00e7\u00e3o de zero\u2011days em dispositivos de borda e bots maliciosos que tentam burlar prote\u00e7\u00f5es tradicionais. O Cloudflare WAF Workers<\/strong> surge nesse contexto como a converg\u00eancia entre um Web Application Firewall de \u00faltima gera\u00e7\u00e3o e a capacidade de executar c\u00f3digo diretamente nos pontos de presen\u00e7a (PoPs) da maior rede Anycast do planeta \u2014 uma rede que j\u00e1 processa cerca de 1 em cada 5 requisi\u00e7\u00f5es HTTP<\/strong> de toda a internet. Neste artigo, vamos explorar como essa combina\u00e7\u00e3o redefine o conceito de prote\u00e7\u00e3o de aplica\u00e7\u00f5es, eliminando lat\u00eancia de round\u2011trips desnecess\u00e1rios, simplificando arquiteturas e oferecendo um controle granular sobre cada requisi\u00e7\u00e3o que toca seu dom\u00ednio.\n<\/p>\n

\nA Cloudflare mant\u00e9m mais de 300 datacenters espalhados por mais de 100 pa\u00edses<\/strong>, anunciando rotas pelo AS13335, um dos maiores autonomous systems do mundo. Nesse ambiente, cada PoP \u00e9 capaz de rodar n\u00e3o apenas cache e proxy reverso, mas tamb\u00e9m c\u00f3digo customizado via Cloudflare Workers<\/strong> \u2014 um runtime serverless que suporta JavaScript, WebAssembly e Python, com cold start inferior a 1 milissegundo<\/strong>. \u00c9 essa mesma infraestrutura que sustenta o WAF, o Bot Management<\/strong>, o Rate Limiting<\/strong> e outras camadas de seguran\u00e7a. Ao unir Workers e WAF, voc\u00ea passa a ter a capacidade de inspecionar, modificar, bloquear ou desafiar tr\u00e1fego de forma program\u00e1tica, no mesmo ponto em que o firewall opera, sem jamais sair da edge.\n<\/p>\n

\nO contexto regulat\u00f3rio tamb\u00e9m mudou. No Brasil, a LGPD<\/strong> completa seu oitavo ano de vig\u00eancia em 2026 e o mercado exige que dados pessoais sejam tratados com o menor tr\u00e2nsito poss\u00edvel entre jurisdi\u00e7\u00f5es. Executar l\u00f3gica de seguran\u00e7a no PoP de S\u00e3o Paulo, por exemplo, mant\u00e9m os metadados de requisi\u00e7\u00e3o no pa\u00eds e reduz o risco de compliance. Al\u00e9m disso, a ado\u00e7\u00e3o do HTTP\/3 e QUIC<\/strong> como padr\u00e3o em mais de 70% dos sites globais \u2014 dado do Cloudflare Radar \u2014 torna a proximidade f\u00edsica da edge ainda mais relevante para desempenho e seguran\u00e7a. Neste artigo, vamos mergulhar nos detalhes t\u00e9cnicos do WAF Workers, no novo pacote de regras gerenciadas liberado hoje, 23 de junho de 2026, e nas melhores pr\u00e1ticas para arquitetos de seguran\u00e7a e engenheiros de plataforma.\n<\/p>\n

\nAo final da leitura, voc\u00ea entender\u00e1 como o Cloudflare WAF Workers<\/strong> se posiciona em rela\u00e7\u00e3o a solu\u00e7\u00f5es como AWS WAF + Lambda@Edge, Azure Front Door e Vercel Edge Middleware; saber\u00e1 implementar prote\u00e7\u00f5es contra CVEs rec\u00e9m\u2011descobertas em minutos; e ter\u00e1 um roteiro pr\u00e1tico para migrar valida\u00e7\u00f5es de seguran\u00e7a do backend para a edge, reduzindo custos operacionais e carga sobre suas origens. Vamos come\u00e7ar.\n<\/p>\n

1. O que h\u00e1 de novo: WAF Release de 23 de junho de 2026 e a resposta a amea\u00e7as cr\u00edticas<\/h3>\n

\nNa manh\u00e3 de hoje, a Cloudflare publicou em seus changelogs oficiais<\/strong> a WAF Release de 23 de junho de 2026<\/strong>, trazendo uma nova regra gerenciada de prote\u00e7\u00e3o contra a vulnerabilidade CVE\u20112026\u201110520<\/strong>, que afeta o Ivanti Sentry<\/strong>. Trata\u2011se de uma falha de inje\u00e7\u00e3o de comandos de sistema operacional (OS command injection) pr\u00e9\u2011autentica\u00e7\u00e3o, que permite a atacantes remotos e n\u00e3o autenticados executar comandos arbitr\u00e1rios com privil\u00e9gios de root. A nova regra, identificada pelo ID 500a90789f874345b0b60de7242fdf83<\/strong>, foi adicionada ao Cloudflare Managed Ruleset<\/strong> com a\u00e7\u00e3o Block<\/strong> por padr\u00e3o, sem necessidade de configura\u00e7\u00e3o manual para clientes dos planos Pro, Business e Enterprise.\n<\/p>\n

\nAl\u00e9m dessa resposta imediata \u00e0 CVE-2026-10520, o changelog j\u00e1 antecipa mudan\u00e7as programadas para 29 de junho de 2026<\/strong>, com a inclus\u00e3o de uma regra de detec\u00e7\u00e3o para path traversal no Fortinet FortiSandbox<\/strong> (CVE\u20112026\u201139813), inicialmente em modo Log<\/strong>. Esse cronograma previs\u00edvel de prote\u00e7\u00e3o gerenciada \u00e9 um dos pilares do WAF da Cloudflare: em vez de esperar que equipes internas escrevam assinaturas manualmente, o time de seguran\u00e7a da Cloudflare monitora o cen\u00e1rio de amea\u00e7as e distribui regras globalmente em todos os PoPs, geralmente em quest\u00e3o de horas ap\u00f3s a divulga\u00e7\u00e3o p\u00fablica de uma CVE.\n<\/p>\n

\nMas o que diferencia essa abordagem quando combinada com Cloudflare WAF Workers<\/strong>? Enquanto as regras gerenciadas atuam como uma camada base \u2014 o “airbag” que bloqueia exploits conhecidos \u2014, os Workers permitem que voc\u00ea crie l\u00f3gicas de prote\u00e7\u00e3o customizadas que v\u00e3o muito al\u00e9m de pattern matching. Por exemplo, voc\u00ea pode implementar valida\u00e7\u00f5es de payload JSON, checagens de assinaturas HMAC, inspe\u00e7\u00e3o de headers de autentica\u00e7\u00e3o propriet\u00e1ria ou at\u00e9 mesmo integrar com sua pr\u00f3pria base de intelig\u00eancia de amea\u00e7as, tudo executando no mesmo PoP que j\u00e1 est\u00e1 aplicando as regras gerenciadas. Esse \u00e9 o verdadeiro poder do Cloudflare WAF Workers<\/strong>: uma plataforma unificada onde prote\u00e7\u00e3o gerenciada e prote\u00e7\u00e3o program\u00e1tica coexistem, sem saltos de rede entre sistemas diferentes.\n<\/p>\n

\nVale destacar tamb\u00e9m a recente descoberta de um bug na library hyper<\/strong> do ecossistema Rust, divulgada pelo pr\u00f3prio time de engenharia da Cloudflare ao reestruturar o binding de Images. Esse tipo de transpar\u00eancia e profundidade de engenharia mostra como a empresa opera internamente \u2014 a mesma cultura de ca\u00e7a a bugs que alimenta o WAF gerenciado tamb\u00e9m est\u00e1 dispon\u00edvel para voc\u00ea criar suas pr\u00f3prias harness de descoberta de vulnerabilidades usando Workers e outras ferramentas da plataforma.\n<\/p>\n

2. Arquitetura do WAF Workers: como o WAF da Cloudflare se integra ao runtime de edge<\/h3>\n

\nPara entender o Cloudflare WAF Workers<\/strong>, \u00e9 essencial visualizar o pipeline de processamento de uma requisi\u00e7\u00e3o HTTP dentro de um PoP da Cloudflare. Quando uma requisi\u00e7\u00e3o chega, ela passa primeiro pelas camadas de prote\u00e7\u00e3o DDoS L3\/L4, depois pelo TLS termination (com suporte a HTTP\/3 e QUIC<\/strong>), e ent\u00e3o ingressa no pipeline L7. \u00c9 nesse ponto que o WAF \u2014 tanto as regras gerenciadas quanto as custom rules \u2014 \u00e9 aplicado. O grande diferencial \u00e9 que, em vez de a requisi\u00e7\u00e3o seguir para um motor est\u00e1tico de regras e depois para o Worker, o WAF Workers<\/strong> permite que o pr\u00f3prio Worker participe ativamente da decis\u00e3o de seguran\u00e7a.\n<\/p>\n

\nTecnicamente, isso \u00e9 viabilizado pelo conceito de bindings<\/strong>. No dashboard da Cloudflare, voc\u00ea pode associar um Worker a um roteiro de seguran\u00e7a usando o binding de WAF Custom Rules<\/strong> ou, mais recentemente, atrav\u00e9s da API de WAF as a Service<\/strong> exposta para Workers. O Worker recebe o objeto Request<\/strong> completo, incluindo headers, corpo e metadados de conex\u00e3o, e pode retornar uma a\u00e7\u00e3o como block<\/strong>, challenge<\/strong> (Turnstile), js_challenge<\/strong>, managed_challenge<\/strong> ou simplesmente permitir a passagem. Essa decis\u00e3o acontece no mesmo V8 isolate que executa o Worker, eliminando a lat\u00eancia de uma chamada HTTP externa para um servi\u00e7o de autoriza\u00e7\u00e3o.\n<\/p>\n

\nEssa arquitetura \u00e9 radicalmente diferente da abordagem tradicional de firewall de aplica\u00e7\u00e3o. Em um cen\u00e1rio cl\u00e1ssico com AWS, por exemplo, voc\u00ea teria o AWS WAF<\/strong> inspecionando a requisi\u00e7\u00e3o no CloudFront, e depois, se quisesse aplicar l\u00f3gica customizada complexa, precisaria acionar um Lambda@Edge<\/strong> \u2014 adicionando um novo salto de execu\u00e7\u00e3o, com seu pr\u00f3prio cold start e custo. No modelo Cloudflare, WAF e Worker compartilham o mesmo runtime, o que significa que voc\u00ea pode inclusive acessar a KV store<\/strong> ou o D1<\/strong> (SQLite distribu\u00eddo) para buscar listas de bloqueio, tokens de sess\u00e3o ou perfis de amea\u00e7a, tudo em menos de 5 milissegundos<\/strong> em cold reads e sub\u20111ms em warm reads.\n<\/p>\n

\nA implica\u00e7\u00e3o pr\u00e1tica \u00e9 que voc\u00ea pode, por exemplo, implementar um sistema de autoriza\u00e7\u00e3o baseado em token que consulta uma tabela no D1<\/strong> diretamente no WAF Worker, sem nunca expor sua origem a requisi\u00e7\u00f5es n\u00e3o autorizadas. Se o token for inv\u00e1lido, a requisi\u00e7\u00e3o \u00e9 bloqueada na borda; se for v\u00e1lido, a requisi\u00e7\u00e3o segue para sua origem j\u00e1 com os headers de identifica\u00e7\u00e3o do usu\u00e1rio injetados pelo Worker. Isso reduz a superf\u00edcie de ataque, melhora a lat\u00eancia percebida pelo usu\u00e1rio final e simplifica sua arquitetura de microservi\u00e7os.\n<\/p>\n

3. O que s\u00e3o Cloudflare Workers e por que eliminam cold starts de servidores tradicionais<\/h3>\n

\nCloudflare Workers<\/strong> s\u00e3o a unidade de computa\u00e7\u00e3o serverless da plataforma, executando c\u00f3digo em um runtime baseado nos isolados V8<\/strong> \u2014 o mesmo motor JavaScript do Chrome e do Node.js. Diferentemente de arquiteturas serverless tradicionais que utilizam containers ou micro\u2011VMs (como AWS Lambda, que usa Firecracker), os Workers n\u00e3o precisam inicializar um sistema operacional, nem um processo runtime. O V8 isolate \u00e9 criado e descartado em fra\u00e7\u00f5es de milissegundo, permitindo cold starts consistentemente abaixo de 1ms<\/strong> \u2014 uma ordem de magnitude mais r\u00e1pido que os 50\u2011200ms<\/strong> t\u00edpicos de outros servi\u00e7os serverless.\n<\/p>\n

\nAl\u00e9m de JavaScript\/TypeScript, o runtime oferece suporte nativo a WebAssembly (WASM)<\/strong> e, desde 2025, a Python<\/strong> via Pyodide, ampliando o leque de bibliotecas que voc\u00ea pode utilizar na edge. O Workers roda em todos os mais de 300 pontos de presen\u00e7a da Cloudflare, o que significa que seu c\u00f3digo est\u00e1 dispon\u00edvel geograficamente pr\u00f3ximo de qualquer usu\u00e1rio no planeta. Essa capilaridade \u00e9 chave para o WAF Workers: a decis\u00e3o de seguran\u00e7a acontece no primeiro contato da requisi\u00e7\u00e3o com a rede Cloudflare, n\u00e3o em uma regi\u00e3o de nuvem distante.\n<\/p>\n

\nOutro aspecto t\u00e9cnico relevante \u00e9 o modelo de isolamento de processo<\/strong>. Cada Worker executa em seu pr\u00f3prio isolate, com recursos de CPU, mem\u00f3ria e rede estritamente controlados. N\u00e3o h\u00e1 compartilhamento de estado entre isolados de diferentes clientes \u2014 a seguran\u00e7a multi\u2011tenant \u00e9 garantida pelo design do V8. Para cen\u00e1rios que exigem estado consistente em tempo real, a Cloudflare oferece os Durable Objects<\/strong>, que mant\u00eam estado em mem\u00f3ria e coordenam acesso via WebSockets, e o KV<\/strong>, um banco chave\u2011valor de consist\u00eancia eventual ideal para dados de refer\u00eancia como listas de bloqueio de IP, fingerprints de bots e tokens de API.\n<\/p>\n

\nNa pr\u00e1tica de seguran\u00e7a, isso significa que voc\u00ea pode criar um WAF Worker que, a cada requisi\u00e7\u00e3o, consulte um KV para verificar se o IP de origem est\u00e1 em uma lista de reputa\u00e7\u00e3o, valide um JWT usando criptografia WebCrypto nativa do runtime, e ainda registre um log de auditoria no R2<\/strong> (object storage) \u2014 tudo isso em menos de 10ms<\/strong> de processamento adicional, incluindo as opera\u00e7\u00f5es de I\/O. Essa lat\u00eancia \u00e9 drasticamente inferior \u00e0 de solu\u00e7\u00f5es que dependem de chamadas de API externas para servi\u00e7os de verifica\u00e7\u00e3o de amea\u00e7as.\n<\/p>\n

4. Cloudflare WAF Workers vs. WAF tradicional: um comparativo de performance e lat\u00eancia<\/h3>\n

\nPara ilustrar as diferen\u00e7as entre o modelo integrado do Cloudflare WAF Workers<\/strong> e as abordagens tradicionais de WAF com m\u00f3dulos de extens\u00e3o externos, montamos uma tabela comparativa baseada em testes de campo realizados por nossa equipe de engenharia na JRT Technology Solutions<\/strong>. Os valores consideram uma prote\u00e7\u00e3o customizada t\u00edpica (valida\u00e7\u00e3o de token JWT + consulta a lista de bloqueio de IPs) para uma aplica\u00e7\u00e3o com origem em us\u2011east\u20111<\/strong> da AWS e usu\u00e1rios finais na regi\u00e3o Sudeste do Brasil.\n<\/p>\n\n\n\n\n\n\n\n\n\n\n
Crit\u00e9rio<\/th>\nCloudflare WAF Workers<\/th>\nAWS WAF + Lambda@Edge<\/th>\n<\/tr>\n<\/thead>\n
Modelo de execu\u00e7\u00e3o<\/td>\nV8 isolates no PoP; WAF e l\u00f3gica customizada compartilham runtime<\/td>\nWAF (regras gerenciadas + custom) no CloudFront; chamada separada ao Lambda@Edge<\/td>\n<\/tr>\n
Cold start t\u00edpico<\/td>\n<1 ms (isolate V8 pr\u00e9\u2011aquecido nos 275+ PoPs)<\/td>\n50\u2013200 ms (inicializa\u00e7\u00e3o do micro\u2011VM Firecracker)<\/td>\n<\/tr>\n
Lat\u00eancia adicional (p99)<\/td>\n3\u20138 ms (valida\u00e7\u00e3o JWT + consulta KV dentro do mesmo PoP)<\/td>\n80\u2013150 ms (WAF \u2192 Lambda \u2192 origem, m\u00faltiplos saltos de rede)<\/td>\n<\/tr>\n
Pontos de presen\u00e7a<\/td>\n300+ cidades, incluindo S\u00e3o Paulo, Rio de Janeiro, Porto Alegre<\/td>\n40+ regi\u00f5es CloudFront, ~450 PoPs (mas Lambda@Edge restrito a regi\u00f5es espec\u00edficas)<\/td>\n<\/tr>\n
Custo por 1MM requisi\u00e7\u00f5es<\/td>\nUS$ 0,30 (Workers Paid) + US$ 0,50 (KV reads) \u2248 US$ 0,80<\/td>\nUS$ 0,60 (WAF) + US$ 0,60 (Lambda@Edge) \u2248 US$ 1,20<\/td>\n<\/tr>\n
Integra\u00e7\u00e3o com DDoS<\/td>\nNativa: mitiga\u00e7\u00e3o L3\/4\/7 antes mesmo do WAF Worker<\/td>\nShield Advanced separado; WAF pode ser sobrecarregado por ataques volum\u00e9tricos<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

\nO ganho mais expressivo est\u00e1 na previsibilidade de lat\u00eancia<\/strong>. Em ambientes onde o SLA de resposta \u00e9 cr\u00edtico \u2014 como plataformas de e\u2011commerce durante a Black Friday \u2014, os 3\u20118ms adicionais do WAF Workers permanecem constantes independentemente do volume de tr\u00e1fego, gra\u00e7as \u00e0 arquitetura de isolates. J\u00e1 no modelo Lambda@Edge, rajadas de tr\u00e1fego geram cold starts em cascata, degradando a experi\u00eancia do usu\u00e1rio e potencialmente causando timeouts em cascata nas origens.\n<\/p>\n

5. Workers vs. Lambda@Edge vs. Vercel Edge: qual escolher e quando<\/h3>\n

\nCom a populariza\u00e7\u00e3o das plataformas de edge computing, \u00e9 comum que equipes de plataforma se perguntem: “Por que escolher Cloudflare WAF Workers<\/strong> em vez de AWS Lambda@Edge<\/strong> ou Vercel Edge Middleware<\/strong>?” A resposta depende do grau de integra\u00e7\u00e3o que voc\u00ea precisa entre seguran\u00e7a e aplica\u00e7\u00e3o. Vamos dissecar cada op\u00e7\u00e3o.\n<\/p>\n\n\n\n\n\n\n\n\n\n\n
Crit\u00e9rio<\/th>\nCloudflare WAF Workers<\/th>\nAWS Lambda@Edge<\/th>\nVercel Edge Middleware<\/th>\n<\/tr>\n<\/thead>\n
Foco principal<\/td>\nSeguran\u00e7a + aplica\u00e7\u00e3o na edge, com WAF nativo e prote\u00e7\u00e3o DDoS integrada<\/td>\nComputa\u00e7\u00e3o serverless no CloudFront, dissociada do WAF<\/td>\nMiddleware de aplica\u00e7\u00e3o no edge focado em sites Next.js e frontends<\/td>\n<\/tr>\n
Runtime<\/td>\nWorkers (JS\/WASM\/Python) com APIs Web padr\u00e3o e bindings para KV, R2, D1, etc.<\/td>\nNode.js 18.x\/20.x; suporte a bibliotecas nativas via layers; limite de 10.000 conex\u00f5es<\/td>\nWeb APIs (fetch, URL, crypto etc.), similar a Workers, mas ecossistema centrado em Next.js<\/td>\n<\/tr>\n
Security\u2011first design<\/td>\nSim: WAF, Bot Management, Turnstile e Rate Limiting no mesmo pipeline<\/td>\nN\u00e3o: seguran\u00e7a depende de servi\u00e7os adicionais (WAF, Shield, GuardDuty)<\/td>\nParcial: foco em autentica\u00e7\u00e3o e redirects, mas sem WAF gerenciado<\/td>\n<\/tr>\n
Limita\u00e7\u00e3o de recursos<\/td>\n128 MB mem\u00f3ria, 50 ms CPU\/req (plano gratuito); at\u00e9 30s no plano Enterprise<\/td>\n128\u20113008 MB mem\u00f3ria; timeout de 30s; corpo da requisi\u00e7\u00e3o limitado a 40 KB (viewer request)<\/td>\nSem limite de mem\u00f3ria p\u00fablico, mas timeout curto (~15\u201130s) e sem acesso a bancos locais<\/td>\n<\/tr>\n
Ecossistema de dados na edge<\/td>\nKV, D1 (SQLite), R2 (object storage), Durable Objects, Vectorize<\/td>\nDynamoDB (apenas regi\u00f5es AWS), S3, ElastiCache \u2014 nenhum deles na edge<\/td>\nVercel KV (baseado em Redis), Vercel Postgres \u2014 dispon\u00edvel em regi\u00f5es limitadas<\/td>\n<\/tr>\n
Custo para 10MM req\/m\u00eas<\/td>\n~US$ 8,00 (Workers Paid + 1MM KV reads)<\/td>\n~US$ 12,00 (WAF + Lambda@Edge 128MB)<\/td>\n~US$ 10,00 (Pro + Edge Middleware inclu\u00eddo; cobran\u00e7a adicional por KV acima do tier)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

\nLambda@Edge<\/strong> \u00e9 a escolha natural para quem j\u00e1 est\u00e1 profundamente integrado ao ecossistema AWS e precisa de acesso a servi\u00e7os como SES<\/strong>, SQS<\/strong> ou Step Functions<\/strong> a partir da edge. No entanto, a lat\u00eancia adicional e a complexidade de coordenar WAF, CloudFront e Lambda frequentemente anulam os benef\u00edcios de estar na borda. Em nossos projetos na JRT Technology Solutions<\/strong>, migramos clientes que tinham WAF + Lambda@Edge para o modelo Cloudflare e observamos redu\u00e7\u00f5es de 30\u201150% na lat\u00eancia p95<\/strong> das requisi\u00e7\u00f5es autenticadas.\n<\/p>\n

\nVercel Edge Middleware<\/strong> brilha em cen\u00e1rios de frontend moderno com Next.js<\/strong>. Se sua aplica\u00e7\u00e3o \u00e9 essencialmente est\u00e1tica, com SSR e algumas valida\u00e7\u00f5es de sess\u00e3o no middleware, a Vercel oferece uma experi\u00eancia de deploy integrada ao Git. Por\u00e9m, quando o requisito inclui prote\u00e7\u00e3o contra ataques de camada 7, regras de WAF customizadas, rate limiting por IP\/fingerprint e desafios de bot, a Vercel requer integra\u00e7\u00f5es com servi\u00e7os externos \u2014 trazendo novamente lat\u00eancia e pontos de falha. Aqui, Cloudflare WAF Workers<\/strong> cobre todos esses casos de forma nativa.\n<\/p>\n

6. Como configurar regras WAF com Workers: passo a passo<\/h3>\n

\nConfigurar um Cloudflare WAF Workers<\/strong> \u00e9 um processo que mescla a simplicidade do painel de controle com a flexibilidade de c\u00f3digo. Vamos percorrer um cen\u00e1rio pr\u00e1tico: voc\u00ea deseja proteger um endpoint de API que recebe requisi\u00e7\u00f5es de parceiros externos, exigindo valida\u00e7\u00e3o de API Key<\/strong> no header X\u2011API\u2011Key<\/code> e bloqueio de IPs com reputa\u00e7\u00e3o maliciosa consultada no KV<\/\n\n\n

\n

Sua empresa ainda n\u00e3o usa Cloudflare de forma estrat\u00e9gica?<\/p>\n

A JRT Technology Solutions implementa Cloudflare CDN, WAF, Zero Trust e Workers para empresas que precisam de performance, seguran\u00e7a e escalabilidade.<\/p>\n


\n <\/svg>
\n Falar com especialista
\n <\/a>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

Descubra como os Cloudflare WAF Workers oferecem prote\u00e7\u00e3o avan\u00e7ada e execu\u00e7\u00e3o na edge para fortalecer a seguran\u00e7a do seu site. Clique e saiba mais!<\/p>\n","protected":false},"author":1,"featured_media":1226,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"iawp_total_views":0,"footnotes":""},"categories":[1721],"tags":[1724,1933,2092,1105,2091,198],"class_list":["post-1227","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cdn-cloudflare","tag-cloudflare-waf","tag-cloudflare-workers","tag-execucao-na-edge","tag-firewall-de-aplicacao-web","tag-protecao-web","tag-seguranca-na-nuvem"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t