Securitatea aplicațiilor web în 2026: top 10 vulnerabilități și cum le previi din faza de development

OWASP Top 10 explicat pentru manageri și developeri: SQL Injection, XSS, CSRF, configurări greșite, autentificare slabă și supply chain security.

Securitatea aplicațiilor web nu mai este un subiect rezervat doar departamentelor IT. În 2026, orice aplicație business care colectează date, gestionează utilizatori, procesează plăți, stochează documente sau oferă acces clienților poate deveni o țintă.

Pentru manageri, securitatea înseamnă protejarea afacerii: datele clienților, reputația companiei, continuitatea operațională și conformitatea legală. Pentru developeri, securitatea înseamnă decizii concrete în fiecare etapă: cum validăm inputurile, cum construim autentificarea, cum stocăm parolele, cum configurăm serverul, cum gestionăm erorile și cum monitorizăm aplicația după lansare.

O greșeală frecventă este tratarea securității ca etapă finală. Se construiește aplicația, se lansează aproape complet, iar la final cineva întreabă: „Este sigură?” În realitate, securitatea trebuie gândită din faza de analiză, proiectare și development. Este mult mai ieftin să previi vulnerabilitățile decât să le repari după ce aplicația este în producție.

Un reper important pentru aplicațiile web este OWASP Top 10, lista celor mai importante riscuri de securitate pentru aplicații. Nu este o listă de atacuri exotice, ci un ghid practic despre greșelile care apar frecvent în software real: acces necontrolat, configurări greșite, componente vulnerabile, autentificare slabă, injection, lipsă de loguri și design nesigur.

Acest articol explică top 10 riscuri într-un limbaj accesibil pentru manageri, dar include și recomandări tehnice pentru echipele de development.

1. Broken Access Control — când utilizatorii văd sau modifică ce nu ar trebui

Pentru manageri, Broken Access Control înseamnă simplu: un utilizator ajunge să acceseze date sau funcții pentru care nu are drepturi. De exemplu, un client vede factura altui client, un angajat fără rol de admin modifică utilizatori sau un partener poate descărca documente care nu îi aparțin.

Aceasta este una dintre cele mai grave clase de vulnerabilități, pentru că afectează direct confidențialitatea și controlul asupra datelor.

Pentru developeri, prevenția începe cu regula: nu verificăm permisiunile doar în interfață. Faptul că un buton nu apare în UI nu înseamnă că endpointul este protejat. Controlul de acces trebuie verificat pe backend, la fiecare operațiune importantă.

Soluții concrete

• Definește roluri și permisiuni clare.
• Verifică autorizarea pe server, nu doar în frontend.
• Folosește politici de acces centralizate.
• Testează cazuri negative: utilizator fără drepturi, client cu alt ID, rol limitat.
• Nu expune ID-uri fără verificarea proprietarului resursei.
• Aplică principiul least privilege: fiecare utilizator vede doar ce are nevoie.

Exemplu simplu: dacă URL-ul /invoices/123 returnează factura 123, aplicația trebuie să verifice dacă utilizatorul autentificat are dreptul să vadă factura 123. Nu este suficient să fie logat.

2. Security Misconfiguration — aplicația este bună, dar configurată prost

Security Misconfiguration apare atunci când aplicația, serverul, baza de date, framework-ul sau serviciile cloud sunt configurate nesigur. Pentru manageri, aceasta înseamnă că produsul poate fi vulnerabil nu din cauza funcționalităților, ci din cauza setărilor greșite.

Exemple frecvente:

• Debug mode activ în producție.
• Mesaje de eroare care afișează detalii interne.
• Panouri administrative expuse public.
• Permisiuni prea largi pe fișiere.
• Servere fără update-uri.
• Bucket-uri de storage publice.
• Parole default.
• CORS configurat prea permisiv.
• Lipsă HTTPS.

Pentru developeri și DevOps, prevenția înseamnă standardizare și checklisturi. Nu trebuie ca fiecare deployment să fie făcut manual „din memorie”.

Soluții concrete

• Folosește configurații separate pentru development, staging și producție.
• Dezactivează debug mode în producție.
• Nu expune stack traces utilizatorilor.
• Folosește HTTPS peste tot.
• Limitează accesul la admin panel.
• Configurează corect CORS.
• Rulează scanări automate de configurare.
• Documentează setările critice.
• Automatizează deploymentul, ca să reduci pașii manuali.

O aplicație poate avea cod bun, dar dacă serverul este configurat greșit, riscul rămâne mare.

3. Software Supply Chain Failures — riscul din biblioteci, pachete și dependențe

Aplicațiile moderne nu sunt construite complet de la zero. Folosesc framework-uri, librării, pachete npm, module Python, imagini Docker, pluginuri, SDK-uri și servicii externe. Acest lucru este normal, dar introduce riscuri.

Pentru manageri, supply chain security înseamnă să înțelegi că aplicația ta depinde și de cod scris de alții. Dacă o bibliotecă folosită în proiect are o vulnerabilitate, aplicația poate deveni vulnerabilă chiar dacă echipa ta a scris cod corect.

Pentru developeri, prevenția înseamnă control asupra dependențelor.

Soluții concrete

• Folosește lock files pentru versiuni predictibile.
• Actualizează periodic dependențele.
• Rulează scanări de vulnerabilități pentru pachete.
• Evită librăriile abandonate.
• Verifică popularitatea și mentenanța pachetelor.
• Nu instala pachete necunoscute fără review.
• Semnează și verifică artefactele de build unde este cazul.
• Folosește CI/CD cu verificări automate.

Pentru aplicații business, dependențele trebuie tratate ca parte din securitate, nu ca detaliu tehnic.

4. Cryptographic Failures — date sensibile protejate insuficient

Cryptographic Failures apar când datele sensibile nu sunt protejate corect. Pentru manageri, exemplele sunt clare: parole stocate greșit, date personale transmise fără criptare, backupuri necriptate sau informații sensibile vizibile în loguri.

Criptarea nu este doar pentru bănci. Orice aplicație care gestionează date personale, contracte, facturi, documente, programări, informații medicale sau date financiare trebuie să protejeze aceste informații.

Pentru developeri, câteva reguli sunt esențiale:

• Nu stoca parole în clar.
• Folosește algoritmi de hashing specializați pentru parole.
• Folosește HTTPS.
• Criptează backupurile.
• Nu salva tokenuri sau parole în loguri.
• Nu inventa algoritmi proprii de criptare.
• Gestionează secretele în servicii dedicate, nu în cod.
• Rotește cheile și credentialele când este nevoie.

Un exemplu important: parolele nu se criptează reversibil, ci se hash-uiesc cu algoritmi potriviți pentru parole. Dacă baza de date este compromisă, parolele nu trebuie să poată fi citite direct.

5. Injection — SQL Injection și alte forme de input periculos

Injection apare când aplicația primește date de la utilizator și le introduce nesigur în comenzi, query-uri sau interpretări interne. Cea mai cunoscută formă este SQL Injection.

Pentru manageri, SQL Injection înseamnă că un atacator poate manipula câmpuri aparent normale, cum ar fi login, căutare sau filtre, pentru a accesa sau modifica date din baza de date.

Pentru developeri, cauza clasică este concatenarea inputului direct în query-uri.

Soluții concrete

• Folosește query-uri parametrizate.
• Folosește ORM-uri corect configurate.
• Validează inputurile.
• Nu construi query-uri SQL prin concatenare de stringuri.
• Limitează drepturile userului de bază de date.
• Tratează toate inputurile ca neîncredere: formulare, URL-uri, headers, fișiere, API payloads.
• Testează endpointurile cu inputuri neașteptate.

Injection nu se limitează la SQL. Poate apărea și în comenzi de sistem, NoSQL, LDAP, template engines sau alte interpretoare. Regula generală este aceeași: datele utilizatorului nu trebuie să devină comandă executabilă.

6. Insecure Design — problema este în arhitectură, nu doar în cod

Insecure Design este una dintre cele mai importante categorii, pentru că arată că securitatea nu se rezolvă doar cu patch-uri. Uneori, aplicația este nesigură pentru că procesul a fost gândit greșit.

Pentru manageri, un exemplu simplu este lipsa limitelor pentru încercări de autentificare. Codul poate funcționa perfect, dar designul permite atacuri de tip brute force. Alt exemplu: un flux de aprobare financiară permite unei singure persoane să creeze și să aprobe o plată fără verificare.

Pentru developeri și arhitecți, prevenția înseamnă threat modeling: analizarea riscurilor încă din faza de design.

Întrebări utile:

• Ce se întâmplă dacă un utilizator abuzează de funcționalitate?
• Ce date sunt sensibile?
• Ce operațiuni trebuie auditate?
• Ce fluxuri au nevoie de aprobare?
• Ce limite aplicăm pentru cereri repetate?
• Ce se întâmplă dacă un API extern eșuează?
• Cum prevenim escaladarea privilegiilor?

Soluții concrete

• Include securitatea în discovery.
• Definește fluxuri de aprobare pentru acțiuni sensibile.
• Folosește rate limiting.
• Introdu separarea responsabilităților.
• Validează scenarii de abuz, nu doar scenarii normale.
• Revizuiește arhitectura înainte de implementare.

Un design sigur previne probleme pe care codul scris bine nu le poate rezolva singur.

7. Authentication Failures — login slab, sesiuni slabe, parole slabe

Authentication Failures apar când aplicația nu verifică identitatea utilizatorilor suficient de sigur.

Pentru manageri, riscul este evident: conturi compromise, acces neautorizat, date furate sau operațiuni făcute în numele altcuiva.

Exemple frecvente:

• Parole slabe acceptate.
• Lipsă protecție la încercări repetate de login.
• Resetare parolă nesigură.
• Tokenuri care nu expiră.
• Sesiuni care nu sunt invalidate la logout.
• Lipsă 2FA pentru administratori.
• Mesaje de eroare care confirmă dacă un email există.

Pentru developeri, autentificarea trebuie tratată ca o zonă critică.

Soluții concrete

• Folosește hashing sigur pentru parole.
• Implementează rate limiting la login.
• Folosește 2FA pentru roluri administrative.
• Nu expune dacă emailul există sau nu.
• Folosește tokenuri cu expirare.
• Invalidează sesiunile la logout și la schimbarea parolei.
• Protejează resetarea parolei cu tokenuri unice și expirabile.
• Monitorizează autentificările suspecte.

Autentificarea este poarta aplicației. Dacă este slabă, restul securității devine mult mai puțin relevant.

8. Software or Data Integrity Failures — când nu poți avea încredere în cod sau date

Această categorie se referă la situații în care aplicația acceptă cod, update-uri, fișiere sau date fără verificări suficiente.

Pentru manageri, riscul este ca sistemul să proceseze date manipulate sau să ruleze cod nesigur. De exemplu, un update compromis, un fișier încărcat fără validare sau o integrare care acceptă payloaduri neverificate poate crea probleme majore.

Pentru developeri, integritatea înseamnă verificare și control.

Soluții concrete

• Validează fișierele încărcate.
• Limitează tipurile și dimensiunile fișierelor.
• Scanează fișierele unde este cazul.
• Nu executa fișiere încărcate de utilizatori.
• Semnează update-urile sau artefactele importante.
• Folosește pipeline-uri CI/CD securizate.
• Protejează branchurile principale.
• Cere review pentru pull requesturi.
• Validează webhookurile prin semnături.
• Nu accepta date critice din surse externe fără verificare.

Integritatea este esențială în aplicații care procesează documente, plăți, comenzi, contracte, facturi sau informații operaționale.

9. Security Logging and Alerting Failures — nu vezi atacul, deci nu poți reacționa

O aplicație poate fi atacată fără ca echipa să observe. Lipsa logurilor și alertelor transformă incidentele în surprize târzii.

Pentru manageri, logurile sunt importante pentru investigații, conformitate și continuitate. Dacă apare o problemă, trebuie să știi ce s-a întâmplat, cine a accesat, ce s-a modificat și când.

Pentru developeri, loggingul trebuie proiectat atent. Nu logăm parole, tokenuri sau date sensibile inutile. Dar logăm acțiunile importante.

Ce merită logat:

• Login reușit și eșuat.
• Schimbare parolă.
• Schimbare rol.
• Export de date.
• Ștergere date.
• Modificare documente.
• Acțiuni administrative.
• Erori critice.
• Cereri suspecte.
• Acces la resurse sensibile.

Soluții concrete

• Definește loguri de securitate încă din dezvoltare.
• Folosește niveluri clare: info, warning, error, critical.
• Protejează logurile împotriva modificării.
• Setează alerte pentru evenimente critice.
• Monitorizează rate de erori și autentificări eșuate.
• Păstrează logurile conform unei politici de retenție.

Un sistem fără loguri este ca o clădire fără camere, fără alarme și fără registru de acces.

10. Mishandling of Exceptional Conditions — erori tratate prost, risc crescut

Această categorie se referă la modul în care aplicația gestionează situațiile excepționale: erori, timeout-uri, răspunsuri incomplete, API-uri externe căzute, date lipsă, fișiere invalide sau operațiuni întrerupte.

Pentru manageri, problema apare când o eroare tehnică devine problemă de business: comandă dublată, plată procesată greșit, raport incorect, document pierdut sau utilizator blocat.

Pentru developeri, prevenția înseamnă tratarea controlată a erorilor.

Soluții concrete

• Nu afișa utilizatorilor detalii interne ale erorilor.
• Tratează timeout-urile și retry-urile.
• Folosește tranzacții pentru operațiuni critice.
• Validează datele înainte de procesare.
• Asigură idempotency pentru plăți și comenzi.
• Definește fallback pentru servicii externe.
• Loghează erorile critice.
• Afișează mesaje clare, dar sigure.
• Testează scenarii de eșec, nu doar scenarii normale.

O aplicație matură nu este cea în care nu apare niciodată o eroare. Este cea care gestionează erorile fără să piardă date, fără să expună informații și fără să blocheze businessul.

Unde intră XSS, CSRF și SQL Injection?

SQL Injection intră în categoria Injection și rămâne una dintre vulnerabilitățile clasice ale aplicațiilor web.

XSS, adică Cross-Site Scripting, apare atunci când un atacator reușește să introducă scripturi sau conținut periculos care rulează în browserul altui utilizator. Pentru manageri, asta poate însemna furt de sesiuni, acțiuni făcute în numele utilizatorului sau compromiterea interfeței. Pentru developeri, prevenția înseamnă output encoding, sanitizare atentă, Content Security Policy, evitarea inserării nesigure de HTML și folosirea corectă a framework-urilor moderne.

CSRF, adică Cross-Site Request Forgery, apare când un utilizator autentificat este păcălit să trimită o cerere nedorită către o aplicație în care este deja logat. Deși nu apare ca o categorie separată în topul OWASP 2025, rămâne relevant în aplicațiile care folosesc cookie-based authentication. Prevenția include CSRF tokens, SameSite cookies, verificarea origin/referrer pentru operațiuni sensibile și evitarea operațiunilor de modificare prin GET.

Aceste vulnerabilități trebuie testate explicit, chiar dacă sunt „clasice”. Tocmai pentru că sunt cunoscute, atacatorii le verifică des.

Cum prevenim vulnerabilitățile din faza de development

Securitatea nu trebuie lăsată pentru final. O abordare sănătoasă include securitatea în fiecare etapă.

• În discovery, identificăm datele sensibile, rolurile, fluxurile critice și cerințele de conformitate.
• În design, definim accesul, permisiunile, auditul, rate limitingul, validările și fluxurile de aprobare.
• În development, folosim coding standards, validare input, query-uri parametrizate, hashing sigur, protecții XSS/CSRF și verificări de autorizare.
• În code review, verificăm nu doar calitatea codului, ci și riscurile de securitate.
• În testing, rulăm scenarii normale și scenarii de abuz.
• În deployment, folosim configurații securizate, secrete gestionate corect, HTTPS, backup și CI/CD.
• După lansare, monitorizăm loguri, actualizăm dependențe, aplicăm patch-uri și verificăm periodic aplicația.

Checklist scurt pentru manageri

Înainte să lansezi o aplicație web, întreabă echipa:

• Avem roluri și permisiuni clare?
• Datele sensibile sunt protejate?
• Parolele sunt stocate corect?
• Există 2FA pentru administratori?
• Există protecție împotriva SQL Injection, XSS și CSRF?
• Avem loguri pentru acțiuni importante?
• Există backup și restore testat?
• Dependențele sunt actualizate?
• Serverul este configurat securizat?
• Există plan de reacție la incidente?

Dacă răspunsurile sunt neclare, aplicația nu este pregătită suficient.

Checklist scurt pentru developeri

Pentru fiecare funcționalitate nouă, verifică:

• Inputurile sunt validate?
• Outputul este encodat corect?
• Query-urile sunt parametrizate?
• Endpointul verifică autentificarea?
• Endpointul verifică autorizarea?
• Datele sensibile nu ajung în loguri?
• Erorile sunt tratate controlat?
• Operațiunile critice sunt auditate?
• Există teste pentru scenarii de abuz?
• Dependențele folosite sunt sigure și actuale?

Această disciplină reduce riscurile înainte ca ele să ajungă în producție.

Concluzie

Securitatea aplicațiilor web în 2026 nu mai poate fi tratată ca o opțiune. Pentru orice companie care colectează date, oferă conturi utilizatorilor, procesează documente, gestionează plăți sau automatizează procese interne, securitatea este parte din produs.

OWASP Top 10 oferă o hartă bună a celor mai importante riscuri: acces necontrolat, configurări greșite, supply chain, criptografie slabă, injection, design nesigur, autentificare vulnerabilă, integritate, logging insuficient și tratarea greșită a erorilor.

Pentru manageri, mesajul este simplu: securitatea protejează businessul. Pentru developeri, mesajul este la fel de clar: securitatea se construiește în cod, în arhitectură, în configurare și în procesul de livrare.

Aplicațiile sigure nu apar întâmplător. Ele sunt rezultatul unei metode: analiză corectă, design atent, dezvoltare disciplinată, testare serioasă, deployment controlat și monitorizare continuă.

Într-un proiect software modern, întrebarea nu este „avem timp pentru securitate?”, ci „ne permitem să o ignorăm?”.