Audit de securitate pentru aplicații web

Dacă ai ajuns aici, probabil cineva ți-a cerut „un audit de securitate”: un client enterprise înainte să semneze, un auditor ISO 27001, un investitor aflat în due diligence sau propriul tău CTO după un incident evitat la limită. Problema e că, pe piața din România (și nu numai), termenul e folosit pentru orice, de la un raport generat automat de un scaner în 10 minute până la o analiză de cod de câteva săptămâni. Prețurile diferă de zeci de ori între oferte, iar livrabilele la fel.

Ghidul ăsta îți explică ce acoperă un audit de securitate pentru o aplicație web, prin ce diferă de un pentest și de o scanare de vulnerabilități, cum arată procesul, de la un capăt la altul, ce conține un raport bun și cum alegi un furnizor fără să plătești bani serioși pe un PDF fără valoare.

---

Cele trei se confundă constant, inclusiv în oferte comerciale. Distincția nu e una de manual: determină ce primești, cât plătești și ce poți demonstra ulterior unui client sau auditor.

Scanarea de vulnerabilități e un proces automat. Un tool (Nessus, ZAP, Burp Scanner, un SAST oarecare) rulează pe aplicație sau pe cod și raportează pattern-uri cunoscute: biblioteci vechi, headere lipsă, endpoint-uri care răspund suspect. E ieftină, rapidă și utilă ca igienă continuă. Dar nu validează exploatabilitatea, nu înțelege logica de business și produce zgomot: false positives care trebuie triate de un om.

Pentestul e un exercițiu ofensiv: un om (sau, tot mai des, un sistem AI specializat) încearcă să compromită aplicația într-o fereastră de timp definită. Rezultatul e o listă de vulnerabilități demonstrate, cu pași de reproducere. Pentestul răspunde la întrebarea „poate fi spartă aplicația asta, aici și acum, pe perimetrul ăsta?”.

Auditul de securitate e evaluarea cea mai cuprinzătoare dintre cele trei. Trece dincolo de „ce am reușit să exploatez” și răspunde la o întrebare mai largă: „unde e slabă aplicația asta și de ce?”. Un audit serios combină mai multe metode (analiză de cod, testare dinamică, review de arhitectură, verificarea configurațiilor) și acoperă sistematic suprafața de atac, nu doar punctele unde un atacator a avut noroc în două săptămâni de testare.

Comparativ:

Dacă un furnizor îți vinde „audit de securitate” și livrabilul e exportul brut al unui scaner, ai primit prima linie din tabel la prețul ultimei. Revenim imediat la asta, la capitolul red flags.

---

„Audit de securitate pentru aplicații web” e un termen-umbrelă. Sub el intră câteva tipuri distincte, care se aleg în funcție de acces, buget și întrebarea la care vrei răspuns.

Audit de cod sursă (white-box)

Auditorul primește acces complet la cod și analizează aplicația din interior: fluxuri de autentificare și autorizare, validarea input-ului, criptografie, gestiunea sesiunilor, query-uri către baza de date, integrări cu servicii externe. E metoda cu cea mai bună acoperire pentru vulnerabilitățile de logică: un IDOR subtil sau o verificare de permisiuni lipsă se vede în cod mult mai clar decât din exterior.

Dezavantajul istoric a fost costul: citirea atentă a unui codebase de zeci de mii de linii cere multe ore de om cu experiență, deci auditurile de cod complete erau rezervate companiilor cu bugete mari. Aici s-au schimbat cel mai mult lucrurile în ultimii ani: platforme de audit de cod bazate pe AI, cum e AISafe, parcurg întregul codebase sistematic, nu doar fișierele pe care un om apucă să le citească în fereastra contractată, și validează fiecare ipoteză înainte să o raporteze, la un cost de câteva ori mai mic.

Pentest black-box

Testerul pornește exact ca un atacator extern: un URL, eventual un cont de utilizator, și atât. E cel mai apropiat de realitatea unui atac oportunist și excelent pentru a valida perimetrul: ce vede internetul, ce poate face un utilizator autentificat rău-intenționat, cât de departe se ajunge fără cunoștințe interne. Limita e la fel de clară: ce nu găsește testerul în timpul alocat rămâne negăsit, iar vulnerabilitățile adânci în logica aplicației pot scăpa.

Gray-box

Compromisul practic dintre cele două: testerul primește documentație, conturi cu roluri diferite, eventual acces parțial la cod sau la scheme de API. Elimină timpul pierdut pe recunoaștere și concentrează efortul spre zonele riscante. Pentru majoritatea aplicațiilor SaaS, e raportul calitate-preț cel mai bun dacă alegi un singur exercițiu dinamic.

Audit de arhitectură

Se uită la deciziile de design riscante: unde sunt trasate granițele de încredere, cum circulă secretele, ce se întâmplă dacă un serviciu e compromis, cum arată modelul de amenințări. E ieftin raportat la valoarea lui: o problemă de arhitectură prinsă pe whiteboard costă mult mai puțin decât aceeași problemă refactorizată după doi ani de producție.

Audit de configurare și cloud

Aplicația poate fi impecabilă și totuși expusă: bucket-uri de storage publice, secrete ajunse în loguri prin variabile de mediu, security groups permisive, TLS configurat greșit, CI/CD cu permisiuni excesive. Auditul de configurare verifică infrastructura pe care rulează aplicația. În 2026, pentru majoritatea echipelor, asta înseamnă cloud și Kubernetes, iar greșelile de configurare rămân una dintre cauzele principale ale breșelor: nu întâmplător Security Misconfiguration a urcat pe locul 2 în OWASP Top 10:2025↗.

Un audit complet combină de regulă două sau trei dintre acestea. Combinația clasică pentru o aplicație web: audit de cod + pentest gray-box + review de configurare.

---

Indiferent de furnizor, un audit serios trece prin aceleași etape. Dacă una lipsește din ofertă, întreabă de ce.

1. Stabilirea perimetrului. Stabilești împreună cu furnizorul ce intră în audit: care aplicații, ce mediu (staging sau producție), care repo-uri, ce e exclus explicit. Tot aici se fixează regulile de testare: ferestre de testare, conturi de test, notificare imediată la orice vulnerabilitate critică (nu la finalul proiectului). Un perimetru prost definit e sursa numărul unu de audituri dezamăgitoare: dacă auditorul nu a înțeles ce face aplicația și unde doare, va testa mecanic.

2. Acces și pregătire. Conturi cu fiecare rol relevant, acces la cod pentru componenta white-box, documentație de API, eventual o sesiune scurtă în care echipa ta explică arhitectura. Context bun înseamnă mai puțin timp ars pe recunoaștere și mai mult pe analiză reală.

3. Testarea propriu-zisă. Analiza de cod, testarea dinamică și verificarea configurațiilor, în funcție de tipurile alese. La un audit de calitate, fiecare posibilă vulnerabilitate e validată înainte să ajungă în raport: auditorul construiește un proof of concept sau demonstrează fluxul exploatabil în cod, nu copiază alerta unui tool. Asta e, de altfel, filosofia după care am construit AISafe: agenții noștri nu raportează o suspiciune până nu au urmărit întregul flux de la input controlat de atacator până la impact real, exact cum am arătat în comparația noastră cu prompt-urile generice de „security audit”↗.

4. Raportarea. Livrabilul principal. Detaliem mai jos ce trebuie să conțină, pentru că aici se vede diferența dintre un audit bun și unul scump degeaba.

5. Remedierea. Formal e treaba echipei tale, dar un furnizor bun rămâne disponibil pentru întrebări: „e suficient fix-ul ăsta?”, „care e ordinea corectă de prioritizare?”. Recomandările din raport trebuie să fie suficient de concrete încât un developer să le implementeze fără să devină el însuși expert în securitate.

6. Retestarea. După ce ai aplicat fix-urile, auditorul verifică fiecare vulnerabilitate raportată și confirmă că e închisă și că fix-ul nu poate fi ocolit printr-o variantă a aceluiași atac. Fără retest, ai o listă de probleme, nu o confirmare că le-ai rezolvat. Clarifică încă din ofertă dacă retestul e inclus în preț sau se facturează separat.

---

Raportul e ceea ce rămâne după audit, documentul pe care îl vei arăta clientului enterprise, auditorului de conformitate sau board-ului. Un raport de calitate conține, pentru fiecare vulnerabilitate:

• Titlu clar și severitate justificată, de regulă cu scor CVSS↗ (v3.1 sau v4.0, ultima fiind versiunea curentă publicată de FIRST). Important: scorul trebuie contextualizat. Un SQL injection pe un endpoint intern accesibil doar adminilor nu are aceeași severitate ca unul pre-autentificare, oricât ar semăna semnătura tehnică.
• Pași de reproducere compleți: request-uri concrete, payload-uri, capturi, fragmente de cod vulnerabile cu fișier și linie. Regula de aur: un developer din echipa ta trebuie să poată reproduce problema în câteva minute, fără să contacteze auditorul.
• Impact concret asupra businessului, nu formulări generice. „Un atacator autentificat poate citi facturile oricărui alt tenant” spune ceva; „poate duce la scurgeri de date” nu spune nimic.
• Remediere specifică aplicației tale: ce funcție se schimbă, ce abordare, eventual un exemplu de cod, plus referința la clasa de slăbiciune (CWE↗) pentru context.
• Un sumar executiv inteligibil pentru non-tehnici: nivelul general de securitate, temele recurente (de exemplu „autorizarea se verifică neuniform, de la controller la controller”), riscurile principale în ordinea în care merită atacate.

Temele recurente sunt, poate surprinzător, partea cea mai valoroasă: un bug se repară punctual, dar un pattern sistemic corectat previne următoarele zece.

Red flags: cum recunoști un audit slab

• Raport de scaner vândut ca audit. Dacă raportul arată ca un export din Nessus sau dintr-un SAST (sute de „findings” fără validare, fără pași de reproducere, cu severități copiate mecanic din baza de date a tool-ului), nu ai primit un audit. Testul simplu: cere un exemplu de raport anonimizat înainte să semnezi.
• Nimeni nu a triat false positives. Orice metodă automată produce zgomot. Dacă furnizorul nu l-a filtrat, îl vei filtra tu, plătind de două ori.
• Doar severități mici pe o aplicație care nu a mai fost testată niciodată. O primă evaluare care găsește exclusiv headere lipsă și versiuni de biblioteci e aproape sigur superficială.
• Severități umflate. Reversul: „critical” pe fiecare header lipsă. Severitatea fără context de exploatabilitate e marketing.
• Niciun rezultat negativ documentat. Un audit bun spune și ce a fost testat fără rezultat, altfel nu poți distinge „am verificat și e ok” de „n-am apucat”.
• Refuzul retestului sau lipsa oricărei discuții despre remediere.

---

Nu trebuie să le știi pe de rost, dar trebuie să le recunoști în oferte și rapoarte. Verifică de fiecare dată la ce versiune se referă furnizorul:

• OWASP Top 10↗: cea mai cunoscută listă de categorii de risc pentru aplicații web. Versiunea curentă e Top 10:2025 (prima actualizare de după 2021), cu Broken Access Control pe primul loc și două categorii noi, printre care Software Supply Chain Failures. E un instrument de conștientizare, nu o metodologie de testare. „Acoperim OWASP Top 10” e un minim, nu un avantaj.
• OWASP WSTG↗ (Web Security Testing Guide): metodologia propriu-zisă de testare, cu scenarii concrete pentru fiecare clasă de probleme. Versiunea stabilă curentă e v4.2. Dacă furnizorul menționează WSTG, e semn că testarea urmează o structură, nu inspirația de moment.
• OWASP ASVS↗ (Application Security Verification Standard): un standard de verificare cu cerințe punctuale pe trei niveluri de rigoare. Versiunea curentă e 5.0, publicată în mai 2025. Ideal ca bază contractuală: „auditul verifică aplicația după cerințele ASVS Level 2” e o promisiune măsurabilă.
• CWE↗ (Common Weakness Enumeration): taxonomia standard a claselor de slăbiciuni (CWE-89 = SQL injection, CWE-79 = XSS). Permite comparații între rapoarte și tool-uri.
• CVSS↗ (Common Vulnerability Scoring System): sistemul standard de evaluare a severității, întreținut de FIRST. Versiunea curentă e v4.0; v3.1 e încă folosită pe scară largă și e perfect acceptabilă, atât timp cât raportul precizează versiunea.

---

Momentele clasice în care un audit se justifică:

• Înainte de lansare, mai ales dacă aplicația procesează plăți, date personale sau date medicale. E ultimul moment în care poți repara ieftin.
• După schimbări majore: o rescriere a autentificării, o integrare nouă cu un provider extern, trecerea la multi-tenant, o migrare de infrastructură. Suprafața de atac s-a schimbat; evaluarea veche nu mai descrie realitatea.
• Pentru vânzări enterprise și due diligence: chestionarul de securitate al unui client mare sau un proces de M&A va cere aproape sigur un raport recent de la o terță parte. Dacă îl ai deja, scurtezi ciclul de vânzare.
• Pentru conformitate: ISO 27001 și SOC 2 cer evaluări periodice ale securității ca parte din managementul riscului, iar în UE directiva NIS2 extinde cerințele de management al riscului cibernetic, inclusiv evaluările regulate, la tot mai multe categorii de companii.
• După un incident: pe lângă investigația propriu-zisă, vrei să știi ce altceva mai e exploatabil pe același pattern.

---

Recomandarea practică pentru o aplicație web activă: o evaluare completă cel puțin anual, plus una punctuală după fiecare schimbare majoră de arhitectură sau de suprafață de atac. Între ele, scanare automată continuă ca igienă.

Modelul „pentest o dată pe an” e un compromis moștenit din vremea în care testarea manuală era singura opțiune și costa prea mult ca s-o repeți. Codul tău se schimbă zilnic, iar evaluarea lui o dată pe an. Între două audituri, regresiile de securitate rămân nedetectate. Platformele de audit continuu acoperă tocmai intervalul ăsta: aceeași profunzime de analiză, rulată la fiecare release în loc de o dată pe an, la un cost care îți permite să o repeți.

---

Indiferent dacă evaluezi o firmă clasică de pentest, un freelancer sau o platformă automată, întrebările astea scot rapid la iveală calitatea:

Pentru costuri, tipuri de soluții și criterii de achiziție, consultă ghidul Totul despre pentest în România în 2026↗.

1. „Îmi arătați un raport anonimizat?” Cel mai puternic filtru. Vezi imediat dacă livrabilul are pași de reproducere, impact contextualizat și remedieri concrete, sau e un export de scaner cu logo.
2. „Ce metodologie urmați?” Răspunsul bun sună a WSTG/ASVS plus adaptare la aplicația ta. Răspunsul prost e o listă de tool-uri.
3. „Cum tratați false positives?” Vrei să auzi: fiecare vulnerabilitate e validată manual sau printr-un exploit demonstrat înainte de raportare.
4. „Ce nu acoperiți?” Un furnizor onest are un răspuns clar (de exemplu: social engineering, DoS, infrastructura clientului). Cine pretinde că acoperă tot nu a înțeles întrebarea.
5. „Retestul e inclus? În ce condiții?”
6. „Cine lucrează efectiv pe proiect?” La firmele clasice, seniorul din ofertă și juniorul care execută pot fi persoane diferite. Întreabă.
7. „Cum protejați codul și datele noastre?” NDA, unde se procesează codul, cine are acces, cât se păstrează artefactele.

Și trade-off-urile, spuse pe șleau: un pentest manual de top aduce creativitate umană acolo unde logica de business e ciudată, dar acoperă doar cât încape în fereastra plătită și nu se repetă ieftin. Scanerele clasice se repetă gratis, dar rămân la suprafață. Platformele AI de audit de cod stau în mijloc (acoperire sistematică a întregului codebase, validare a exploatabilității, cost care permite rulare continuă), dar au și ele limite: nu testează procese organizaționale și nu fac social engineering. Alegerea corectă e rareori „una din trei”; pentru majoritatea echipelor e o combinație, dozată după risc și buget.

---

Noi construim AISafe, așa că îți spunem direct ce anume din definiția de mai sus acoperim. Rulăm audituri de cod sursă white-box și pentesturi black-box și white-box cu agenți AI care parcurg în paralel toată suprafața aplicației, nu doar fișierele care încap în fereastra contractată. Fiecare posibilă vulnerabilitate trece printr-un pas de exploatare într-un mediu izolat înainte să ajungă în raport; ce nu se reproduce nu se raportează, deci triajul de false positives nu ajunge la tine.

Raportul respectă lista din „Cum arată un raport bun”: severitate justificată, pași de reproducere cu fișier și linie, impact concret și rezumat executiv cu temele recurente. Îl poți folosi ca dovadă la SOC 2, ISO 27001 sau NIS2. Rezultatele vin în ore, fără programare cu luni înainte, deci auditul poate rula la fiecare lansare de versiune, iar între rulări facem review de securitate pe fiecare Pull Request față de modelul de amenințări construit la audit și monitorizăm endpointurile și permisiunile descoperite acolo. Ne integrăm cu GitHub, GitLab, Jira, Linear și pipeline-ul de CI/CD.

Ca să răspundem și la întrebarea 4 din lista de mai sus, ce nu acoperim: procese organizaționale și social engineering. Poți începe pe planul gratuit, cu audituri de cod pe un singur proiect, și vezi restul pe pagina de prețuri↗.

Ce nu mai are scuză în 2026: să plătești preț de audit pe un PDF pe care nu-l poate reproduce nimeni. Acum știi cum să-l recunoști înainte să semnezi.