Cloudflare a extins firewall-ul de aplicații web cu două capabilități: full transaction detections și response rules. Pe scurt, WAF-ul nu mai judecă doar cererea care intră, ci se uită și la ce a returnat originea, ca să stabilească dacă un atac a reușit sau a fost doar o încercare. Ambele funcții sunt declarate disponibile general pentru toate planurile, inclusiv Free, iar prima protecție administrată acoperă vulnerabilitatea php2shell. Detaliile sunt în anunțul oficial al Cloudflare.

Diferența pare mică. În practică, schimbă modul în care gândești detecția în securitatea aplicațiilor web.

Ce face de fapt Cloudflare WAF acum

Până acum, regulile WAF lucrau la nivel de cerere. Semnăturile recunoșteau tehnici de atac cunoscute, regulile custom filtrau după IP, cale URL, headere sau corpul cererii, iar rate limiting-ul tăia volumul. Toate acestea opresc traficul înainte să ajungă la origini. E corect pentru multe amenințări, dar are o limită structurală.

O cerere suspectă nu e același lucru cu un exploit reușit. Dacă semnăturile sunt largi, prinzi mai multe atacuri, dar crești șansa de fals pozitiv și rupi aplicația pentru utilizatori legitimi. Dacă restrângi regulile ca să eviți fals pozitivele, lași trafic ambiguu să treacă mai departe.

Ce adaugă Cloudflare: corelarea cererii cu răspunsul pe care îl produce. Detecția pe tranzacție completă răspunde la două întrebări simultan. Cererea arată malițios? Și ce s-a întâmplat când aplicația a procesat-o? Un input suspect urmat de un răspuns care expune date sensibile spune altă poveste decât același input urmat de un reject sau de o eroare.

Exemplul din anunț e limpede: o încercare de path traversal pe un endpoint de descărcare fișiere, combinată cu un 200 OK care returnează conținut de tip fișier de configurare. Fiecare semnal separat poate fi zgomot. Împreună, indică expunere de date.

Detecție și blocare, separate intenționat

Arhitectura păstrează o separare pe care merită să o înțelegi, pentru că îți schimbă fluxul de lucru. Detecția analizează traficul și atașează metadate cererii și răspunsului. Regulile decid apoi ce faci cu rezultatul.

Practic, poți vedea întâi ce detectează sistemul pe traficul tău, fără să blochezi nimic. Te uiți în Security Analytics, vezi ce endpoint-uri și ce semnături sunt implicate, apoi decizi ce politică se potrivește aplicației tale. Abia după aceea construiești regula de blocare.

Pe partea tehnică, Cloudflare adaugă câmpuri noi, oglindind câmpurile de detecție pe cerere: cf.waf.signature.response.confidence, cf.waf.signature.response.categories și cf.waf.signature.response.ref (până la 10 ID-uri de referință). Sunt utilizabile în regulile custom pe răspuns și în detecțiile administrate. Compania spune că derulează accesul la aceste câmpuri pentru toate conturile, cu recomandarea de a contacta echipa de cont dacă nu apar încă.

Un detaliu important, enunțat explicit în anunț: response rules pot bloca răspunsul originii înainte să ajungă la solicitant, dar nu pot anula acțiuni deja executate la origine. Dacă un atac a reușit să scrie în baza de date, blocarea răspunsului nu șterge scrierea. Securitatea nu e magie, e limită de infrastructură.

Ce primești pe planul Free și ce rămâne pentru cei plătitori

Aici e partea care contează pentru majoritatea echipelor mici și mijlocii din România. Cloudflare spune că ambele capabilități sunt disponibile general pe toate planurile, inclusiv Free. Concret, toți clienții primesc setul de reguli administrat de răspuns Cloudflare Managed Response Firewall Default, gândit pentru activare simplă, cu posibilitatea de a restrânge domeniul de aplicare, de exemplu pe anumite căi sau excluzând zone.

Toți clienții pot crea până la trei reguli custom pe răspuns, cu acțiuni Log și Block. Câmpurile și funcțiile disponibile în regulile de răspuns oglindesc ce are deja planul tău pe partea de cerere. Regulile pe corpul răspunsului nu sunt încă disponibile, punct clar menționat.

Clienții plătitori primesc în plus acces la rezultatele detecțiilor prin câmpurile cf.waf.signature.response.*, combinabile cu hostname, cale URL, IP sursă sau headere de cerere. Asta permite politici țintite pe un singur path sau cu context specific aplicației.

Cloudflare anunță și direcția de dezvoltare: la început, detecțiile pe tranzacție completă se concentrează pe confirmarea exploatării pentru vulnerabilități de profil înalt, cu extindere ulterioară către expunere de date și semnale de exfiltrare. Pe planurile Free, detecțiile administrate vor urma modelul de la cereri: vulnerabilități cunoscute, catalog mai bogat pentru cei plătitori. Este o intenție declarată, nu o funcție livrată.

Contextul invocat de Cloudflare merită luat în serios. Modelele de frontieră descoperă vulnerabilități îngropate adânc în software larg utilizat, iar agenții AI care scanează pot fi extrem de persistenți: adaptează payload-uri pe baza feedback-ului și lansează atacuri în lanț folosind credențiale și permisiuni. Răspunsul aplicației e exact feedback-ul de care are nevoie un atacator ca să știe dacă merge mai departe.

Cum arată o regulă bună pe răspuns

Exemplul din anunț e instructiv și îl poți folosi ca model de gândire, nu ca rețetă copiată. O regulă care blochează expunerea unei interfețe de administrare atunci când gateway-ul de autentificare nu a marcat cererea ca internă: path care începe cu /admin, header x-internal-user diferit de true, cod 200 și content-type care conține text/html. Blochează doar când o cerere neautentificată țintește /admin și originea returnează efectiv o pagină de administrare. Nu atinge eșecurile normale de autentificare, redirect-urile sau traficul obișnuit.

Ce înveți din asta: condiția pe răspuns e cea care elimină fals pozitivele. Fără http.response.code eq 200 și fără verificarea content-type, regula ar bloca orice acces la /admin, inclusiv login-ul legitim.

Înainte să activezi ceva în producție, fă inventarul endpoint-urilor care returnează date sensibile. Fișiere de configurare, backup-uri, panouri de administrare, API-uri interne, endpoint-uri de export. Apoi pornește în modul Log, nu Block. Uită-te la ce se declanșează, pe ce path-uri, cu ce volum. Abia după ce ai citit evenimentele din Security Events, treci pe blocare, gradual, pe câte o zonă.

Evenimentele generate de regulile pe răspuns apar în Security Events, în secțiunile Managed Rules sau Custom Rules, filtrabile după ID-ul regulii. Momenta, regulile doar pe cerere și cele pe tranzacție completă apar în aceeași pagină de analiză, deci separarea raportării e manuală.

Limitele pe care trebuie să le accepți

Nicio detecție nu e completă. O verificare incompletă nu dovedește absența unei funcții sau a unui element. Dacă nu vezi câmpurile de răspuns în cont, nu înseamnă că funcția nu există, ci că derularea nu a ajuns la tine.

Blocarea pe răspuns vine cu o întârziere logică: decizia se ia după ce originea a procesat deja cererea. Pentru atacuri care doar citesc date, e suficient dacă blochezi răspunsul. Pentru atacuri care scriu, modifică sau creează resurse, blocarea răspunsului nu repară impactul. Aici rămâne esențială prevenția pe cerere, împreună cu validare la nivel de aplicație și permisiuni minime.

Nu transforma o ipoteză în certitudine. Faptul că o regulă administrată acoperă php2shell nu înseamnă că aplicația ta e imună la alte clase de atac. Și nu confunda absența alertelor cu absența atacurilor: dacă nu ai activat detecția în modul Log și nu ai citit evenimentele, nu ai dovada că nu se întâmplă nimic.

Ce înseamnă pentru tine

Dacă ești antreprenor sau marketer român cu un magazin online pe WooCommerce, un site de lead generation sau un SaaS mic, există trei lucruri concrete de făcut, fără să ai echipă de securitate dedicată.

Primul: verifică dacă domeniul trece prin Cloudflare și dacă ai acces la secțiunea Security > Security Rules. Dacă da, activează setul administrat de răspuns și lasă-l în modul Log câteva zile. Nu sări direct la blocare.

Al doilea: gândește-te la endpoint-urile care returnează date. Un magazin are exporturi de comenzi, facturi, fișiere de backup lăsate pe server, panouri de administrare. O regulă simplă care blochează returnarea unei pagini HTML de admin către o cerere neautentificată e ieftină și utilă.

Al treilea: corelează cu ce faci deja. Dacă lucrezi la partea de comerț online, vezi ce schimbi în WooCommerce 11.3 după scoaterea endpointului MCP, pentru că suprafețele de atac se mută odată cu integrările. Iar dacă ai început să folosești agenți AI în operațiuni, problemele reale din producție sunt descrise în analiza despre provocările multi-agent AI. Acolo unde automatizarea crește suprafața de expunere, controlul la nivel de infrastructură devine obligatoriu.

Ce nu face Cloudflare pentru tine: nu îți spune ce e sensibil în aplicația ta, nu îți cunoaște fluxurile legitime și nu îți repară codul. Un WAF bun reduce zgomotul. Nu înlocuiește igiena tehnică.

FAQ

Full transaction detection e disponibil pe planul Free? Da, conform anunțului Cloudflare, ambele capabilități sunt disponibile general pentru toate planurile, inclusiv Free. Toți clienții primesc setul administrat Cloudflare Managed Response Firewall Default și pot crea până la trei reguli custom pe răspuns, cu acțiuni Log și Block. Clienții plătitori primesc acces la câmpurile de detecție cf.waf.signature.response.* pentru politici mai fine.

Response rules pot anula un atac care a modificat deja date? Nu. Cloudflare precizează explicit că regulile pe răspuns blochează răspunsul originii înainte să ajungă la solicitant, dar nu pot anula acțiuni deja efectuate la origine. Pentru atacurile care scriu date, protecția pe cerere și validarea în aplicație rămân esențiale.

Pot bloca după conținutul răspunsului? Nu încă. Crearea de reguli pe corpul răspunsului nu este disponibilă momentan. Poți combina cererea cu proprietăți ale răspunsului precum codul de stare și headerele, nu cu textul din body.

Concluzia ALLSoft: AI-ul ajută, omul decide, execuția se face

Un WAF care corelează cererea cu răspunsul e un instrument bun. Dar un instrument nu are strategie. AI-ul poate accelera analiza: să sintetizeze evenimente din Security Events, să grupeze path-urile care declanșează reguli, să propună scenarii de test. Planning-ul și prioritizarea rămân umane.

Decizia despre ce blochezi, pe ce endpoint și cu ce risc de a rupe fluxul comercial e a unui om care înțelege aplicația. Media buyer-ul și omul tehnic știu ce trafic e legitim, ce campanie aduce bani și unde o regulă agresivă taie conversii. Iar pasul concret, de la detectare în modul Log până la politică de blocare testată în producție, îl face ALLSoft Agency. Fără hype, fără promisiuni de invulnerabilitate, doar verificare pas cu pas și decizii documentate.