OWASP Top 10:
cele zece riscuri, explicate practic

OWASP Top 10 nu este o listă de vulnerabilități, ci o listă de <em>categorii</em> de riscuri, actualizată periodic pe baza datelor din zeci de mii de aplicații. Este referința pe care o citează majoritatea contractelor și a cadrelor de conformitate atunci când spun „testare conform metodologiei recunoscute". Ghidul de mai jos parcurge ediția 2021 — cea în uz general — și arată, pentru fiecare categorie, ce se verifică efectiv într-un test.

A01 — Controlul defectuos al accesului

Prima poziție, și cea mai constantă sursă de incidente reale. Aplicația verifică cine ești, dar nu verifică dacă ai voie să faci exact acțiunea cerută. În practică: schimbi un identificator în URL și vezi factura altui client; apelezi direct un endpoint de administrare pe care interfața nu ți-l arată; modifici un câmp de rol într-o cerere și devii administrator. Niciun scaner nu prinde aceste cazuri, pentru că nu știe cine ar trebui să vadă ce.

A02 — Eșecuri criptografice

Date sensibile transmise sau stocate fără protecție adecvată: trafic pe HTTP, parole stocate cu algoritmi depășiți, chei în codul sursă, date de card sau acte de identitate ținute în clar „temporar". Categoria se numea anterior „expunerea datelor sensibile", iar redenumirea e utilă: problema nu e doar expunerea, ci alegerea greșită a mecanismului de protecție.

A03 — Injecție

Date furnizate de utilizator ajung într-un interpretor fără separare: SQL, comenzi de sistem, LDAP, XPath, template-uri de server. Include și cross-site scripting, mutat aici în ediția 2021. Este categoria pe care uneltele automate o acoperă cel mai bine — și tocmai de aceea, într-un test manual, atenția se duce spre variantele pe care uneltele le ratează: injecția de al doilea ordin, contextele neobișnuite, filtrele care se pot ocoli.

A04 — Design nesigur

Categorie apărută în 2021 și cea mai greu de automatizat: aplicația face exact ce a fost proiectată să facă, iar proiectul este problema. Un flux de recuperare a parolei care se bazează pe o întrebare publică, o limită de rambursare care lipsește din logică, un proces de comandă care poate fi reluat. Aici nu există semnătură de detectat — doar cineva care înțelege business-ul și încearcă să îl folosească greșit.

A05 — Configurare greșită de securitate

Conturi implicite rămase active, mesaje de eroare care dezvăluie structura internă, servicii de administrare expuse, permisiuni prea largi în cloud, funcții de depanare lăsate pornite în producție. Este categoria cu cel mai bun raport între efortul de remediere și riscul eliminat — și, în majoritatea testelor, sursa primei căi de intrare.

A06 — Componente vulnerabile și învechite

Biblioteci, framework-uri și servicii care au vulnerabilități cunoscute și publicate. Categoria care se rezolvă cel mai bine cu automatizare: un inventar al dependențelor și o verificare recurentă rezolvă majoritatea cazurilor. Dificultatea reală nu e detectarea, ci actualizarea — o dependență veche prinsă adânc în cod devine un proiect, nu un patch.

A07 — Eșecuri de identificare și autentificare

Parole slabe permise, lipsa limitării încercărilor, sesiuni care nu expiră, token-uri previzibile, recuperare de cont care poate fi abuzată, autentificare multifactor care poate fi ocolită printr-un flux alternativ. Ultimul caz apare mai des decât s-ar crede: MFA pus pe interfața web, dar nu și pe API-ul mobil.

A08 — Eșecuri de integritate a software-ului și a datelor

Cod sau date acceptate fără verificarea provenienței: actualizări automate nesemnate, biblioteci luate de la surse necontrolate, deserializare a unor obiecte venite de la utilizator, pipeline-uri de livrare în care oricine poate introduce un artefact. Este categoria care corespunde atacurilor asupra lanțului de aprovizionare — motiv pentru care NIS2 și legislația aliniată la ea o tratează separat.

A09 — Eșecuri de jurnalizare și monitorizare

Categoria care nu provoacă niciodată singură o breșă, dar decide cât durează. Evenimente de securitate nejurnalizate, jurnale păstrate doar local și șterse de atacator, alerte care nu ajung la nimeni, imposibilitatea de a reconstitui ce s-a întâmplat. Într-un test, se măsoară simplu: la final, echipa este întrebată ce a observat — iar răspunsul spune mai mult decât lista de constatări.

A10 — Falsificarea cererilor din partea serverului (SSRF)

Aplicația preia o adresă furnizată de utilizator și o accesează ea însăși. Atacatorul o îndreaptă spre rețeaua internă sau spre serviciul de metadate al furnizorului de cloud și obține astfel acces la lucruri pe care nu le poate atinge direct. A intrat în Top 10 în 2021 tocmai pentru că arhitecturile din cloud i-au mărit impactul: o singură cerere bine aleasă poate returna credențiale.

Ce prinde automatizarea și ce cere om

Întrebări frecvente

Ghiduri conexe

• Cât costă un pentest — ce determină prețul, cum se estimează efortul și ce face o ofertă comparabilă cu alta.
• DORA & TLPT — reziliența operațională digitală în sectorul financiar și testarea bazată pe amenințări.
• ISO 27001 & SOC 2 — ce controale cer testare tehnică și ce dovezi acceptă auditorul.
• Legea 48/2023 (Moldova) — cadrul național de securitate cibernetică: cui i se aplică și ce obligații aduce.
• PCI DSS 4.0 — cerințele 11.3 și 11.4, testarea segmentării și ce înseamnă pentru procesatorii de plăți.
• Pentest vs scanare de vulnerabilități — ce găsește fiecare, ce ratează și ce acceptă auditorii ca dovadă.
• Cum te pregătești de pentest — perimetru, acces, reguli de angajament și tot ce se stabilește înainte de prima zi.

Acest material rezumă ediția 2021 a OWASP Top 10 în scop informativ. Lista este actualizată periodic de OWASP; verifică ediția în vigoare atunci când o citezi într-un contract sau într-un dosar de audit.