Art. 21 din OUG nr. 155/2024 include testarea și auditarea măsurilor de securitate printre obligațiile unei entități esențiale sau importante. Art. 24 din DORA cere entităților financiare un program de testare. Niciunul nu spune cum, ceea ce lasă o întrebare practică pentru cine semnează: ce anume îți permite să afirmi o scanare de vulnerabilități fără constatări?
Mai puțin decât se presupune de obicei, iar diferența nu ține de procente de acoperire. Ține de ce poate observa un scaner, în principiu.
Metoda de detecție decide constatarea
Aproape toată testarea automată funcționează pe aceeași buclă: trimite o cerere, citește răspunsul, decide dacă răspunsul arată greșit. Un mesaj de eroare, un stack trace, un payload reflectat, un cod de stare care nu ar trebui să fie acolo.
Bucla are un punct orb încorporat. Două familii mari de vulnerabilități serioase returnează un răspuns perfect normal, iar un instrument care decide citind răspunsuri nu va raporta nimic la niciuna dintre ele. Nu este o problemă de reglaj fin și nu se rezolvă cu o fereastră de scanare mai lungă — dovada pur și simplu nu se află în răspuns.
Conform cifrelor publicate pentru 2025, aceste două familii acoperă cea mai mare parte a vulnerabilităților de API găsite în tot anul.
Prima familie: efectul se produce unde nu te uiți
Un endpoint acceptă o adresă web — o funcție de import, un webhook, un generator de documente care aduce un logo, o previzualizare de link. Serverul aduce adresa primită și returnează obișnuitul 200 OK, pentru că din punctul de vedere al aplicației operațiunea a reușit.
Ce a mai făcut a fost să emită o cerere către o destinație aleasă de un străin. Îndreptat spre o interfață internă de administrare, spre un endpoint de metadate cloud care distribuie credențiale sau spre o bază de date accesibilă din interior dar nu din exterior, serverul aduce și asta. Răspunsul către atacator rămâne generic. Nimic din el nu este anormal.
Server-Side Request Forgery, denumirea formală, a fost prezentă în 33% dintre vulnerabilitățile de API publicate în 2025. Tiparul se repetă în alte clase: o comandă care se execută fără să afișeze nimic, o interogare care rulează în timp ce pagina arată identic în ambele cazuri, un script care se declanșează peste câteva zile în browserul unui administrator. Acestea sunt vulnerabilitățile oarbe sau out-of-band, iar termenul este literal — dovada nu se întoarce niciodată pe canalul pe care îl urmărește instrumentul.
Ca să le găsești, trebuie să renunți la răspuns. Metoda este să dai aplicației un nume de gazdă generat unic, care trimite către un server care ascultă, și apoi să urmărești acel server. Dacă ceva se conectează vreodată, aplicația a executat acțiunea. Conexiunea este dovada; nu e nevoie de niciun răspuns. Aceasta este testarea out-of-band a securității aplicațiilor (OAST) și are două cerințe dure: infrastructură de callback controlată de cel care testează și o adresă distinctă pentru fiecare test, ca fiecare interacțiune să poată fi legată de cererea care a produs-o. Fără prima, aceste vulnerabilități nu pot fi găsite; fără a doua, sunt găsite fără să poți spune unde.
Pentru un dosar de conformitate, distincția ajută într-o direcție utilă. O constatare dedusă dintr-un mesaj de eroare este o inferență. Un server care a contactat efectiv o gazdă cu care nu avea ce discuta este un fapt observat, cu marcaj de timp.
A doua familie: un răspuns valid, livrat cui nu trebuie
A doua familie învinge analiza răspunsurilor din motivul opus. Nimic nu se defectează. Aplicația răspunde corect — cuiva care nu ar fi trebuit să întrebe.
Un utilizator autentificat cere /api/invoices/1042, factura lui. Cere apoi 1043, care aparține altui client, și o primește. API-ul a verificat autentificarea și nu a verificat niciodată proprietatea. Aceasta este autorizarea deficitară la nivel de obiect (BOLA), prezentă în 39% dintre vulnerabilitățile de API publicate în 2025 și cea mai mare categorie din graficul de mai sus. Corespondentul ei, autorizarea deficitară la nivel de funcție (BFLA), aplică aceeași eroare operațiunilor, nu înregistrărilor: un utilizator obișnuit care ajunge la un endpoint administrativ sau care trimite o metodă pe care interfața nu i-a oferit-o niciodată. Ecranul a ascuns butonul; nimeni nu a confirmat că serverul refuză acțiunea.
Ce observă un scaner cu o singură sesiune când cere factura 1043 este o factură validă. Bine formată, cu tipuri corecte, 200 OK. Nu există nicio malformare de identificat și nicio anomalie de punctat. Răspunsul este greșit doar într-un fel care depinde de o informație pe care instrumentul nu o deține — cine deține înregistrarea.
Detectarea cere cel puțin două identități autentificate, o hartă a drepturilor fiecăreia și o comparație între ele: obții un obiect ca proprietar, îl obții din nou cu un cont fără legătură și verifici dacă al doilea cont a primit aceleași date. Vulnerabilitatea există în diferența dintre identități. Nicio analiză a unei singure sesiuni nu o poate scoate la suprafață, motiv pentru care scanerele generaliste de regulă nici nu încearcă, iar constatările de autorizare domină rapoartele de testare manuală.
Ce au făcut breșele, spre deosebire de ce numără scanerele
Numărul de vulnerabilități și cauzele incidentelor sunt seturi de date diferite, iar confundarea lor este felul în care un program ajunge bine apărat față de lucrul greșit.
Din 60 de breșe legate de API făcute publice în 2025, autentificarea deficitară a reprezentat 52%, iar consumul nesigur de API-uri terțe 27%. Eșecul de autorizare apare mai jos, la 10%, ceea ce merită citit atent, nu ca o liniștire: BOLA este categoria principală ca volum de vulnerabilități și o pondere mai mică din breșele publicate, pentru că produce de regulă enumerare și extragere discretă de date, nu genul de eveniment care obligă la notificare. Incidentul Condé Nast din acel set de date — autorizare la nivel de obiect folosită pentru a enumera și extrage înregistrări de abonați — este forma pe care o ia atunci când iese la suprafață.
Două obligații decurg direct. Consumul nesigur, la 27%, este o constatare de lanț de aprovizionare și se mapează pe măsurile de securitate a lanțului de aprovizionare din art. 21, nu pe ceva ce ar arăta o scanare a propriului perimetru. Inventarul gestionat deficitar, la 12%, este problema endpoint-ului uitat — exact motivul pentru care inventarul de active este un control în sine, nu o formalitate administrativă.
Întrebările care stabilesc ce a acoperit o scanare
Când sosește un raport, sau când se alege un furnizor, patru întrebări separă testarea care ar fi putut găsi aceste clase de testarea care nu a fost niciodată poziționată să o facă.
- Se face testare out-of-band, cu infrastructură de callback? Dacă nu, clasele oarbe au fost în afara scopului, indiferent cât de lung e raportul, iar dosarul ar trebui să consemneze asta, nu să sugereze acoperire.
- Câte identități autentificate au fost folosite? Una înseamnă că testarea de autorizare nu a avut loc. Două sau mai multe, cu o hartă definită a drepturilor, înseamnă că putea avea loc.
- S-a ajuns efectiv la endpoint-uri autentificate? Scanarea suprafeței neautentificate nu spune nimic despre logica din spatele unui login, iar majoritatea endpoint-urilor critice pentru business stau în spatele unuia.
- Poate fi urmărită fiecare constatare până la cererea care a produs-o? Pentru un rezultat out-of-band aceasta este corelarea dintre callback și payload și este ceea ce face o constatare sustenabilă la un control.
Un rezultat negativ onest este mai util decât unul sugerat. „Testarea de autorizare nu a fost în scopul acestei scanări" este o linie pe care o poți apăra într-un registru de riscuri. Un raport fără constatări, în care autorizarea nu a fost niciodată testată, este exact lucrul care pică un audit mai târziu, pentru că acolo controlul a fost consemnat ca verificat fără să fi fost examinat.
Unde se află linia
Automatizarea se potrivește bine ambelor familii — OAST pentru clasele oarbe, reluarea cu identități multiple pentru clasele de autorizare — și ambele fac parte din ce rulează ClickScan, cu infrastructură proprie de callback și identități de test separate. Ce stabilește automatizarea este că o verificare anume a rulat pe un endpoint anume și a produs un rezultat anume, repetabil și la cadența pe care o alegi.
Ce nu stabilește este dacă modelul de autorizare este corect în principiu: dacă rolurile au sens de business, dacă un lanț de permisiuni acceptabile individual însumează ceva inacceptabil, dacă un flux poate fi parcurs în altă ordine. Astea sunt întrebări de judecată și sunt rostul unui test de penetrare pe API, alături de o evaluare de vulnerabilități recurentă pentru partea care trebuie să ruleze programat. Stratul de guvernanță și de probe — declarații de scop, hărți de drepturi, ce arată dosarul la un control — ține de audit, risc și conformitate.
Pentru un consiliu de administrație, încadrarea utilă nu este câte constatări a produs o scanare. Este la ce întrebări era metoda capabilă să răspundă și care nu au fost puse niciodată.
Surse: Wallarm API ThreatStats Report 2026 · OWASP API Security Top 10 (2023)
Procentele provin din analiza Wallarm a 67.058 de buletine de securitate publicate în 2025, dintre care 11.053 legate de API, și din evaluarea a 60 de breșe de API făcute publice în același an. Categoriile OWASP se suprapun în cadrul aceleiași vulnerabilități, deci cifrele pe vulnerabilități nu însumează 100%. Nu am verificat independent setul de date Wallarm.
Acest articol are caracter general de informare și nu constituie consultanță juridică sau de reglementare.