OWASP Top 10 în 2026: noile vulnerabilități pe care toți CTOs trebuie să le știe

01A01:2025 Broken Access Control rămâne la vârf

Broken access control rămâne la vârful listei pentru al treilea ciclu consecutiv pentru un motiv simplu: este probabil cea mai răspândită clasă de vulnerabilități în aplicațiile moderne și cea mai greu de detectat automat. SAST și DAST tradiționale au limitări serioase la identificarea acestor probleme; majoritatea apar din logică de business specifică, nu din pattern-uri sintactice.

Cele mai frecvente forme sunt IDOR (Insecure Direct Object Reference), missing authorization la endpoints administrative, privilege escalation prin manipulare de parametri în request-uri și problemele specifice cu JWT-uri care nu validează corect claims sau scope. În aplicații SaaS multi-tenant, broken access control se manifestă des prin posibilitatea de a citi date ale altor tenants prin manipulare directă de IDs în URL.

Recomandarea Blackbone este să implementezi authorization ca middleware central, nu în controllere individuale. Folosește un pattern policy-based unde fiecare resource are reguli explicite și unde absența unei reguli înseamnă deny implicit. Testează manual scenarii de tip horizontal privilege escalation (utilizator A accesează date utilizator B) la fiecare release major. Aceste teste nu pot fi automatizate complet.

• →Implementează authorization ca middleware central cu deny default
• →Folosește IDs UUID v7 sau ULID, nu integers sequențial
• →Validează JWT scope la fiecare endpoint, nu doar autentificarea
• →Testează horizontal privilege escalation la fiecare release
• →Loghează toate access denials și monitorizează anomalii

02A02:2025 Cryptographic Failures cu accent pe key management

Cryptographic failures rămâne pe poziția a doua, dar accentul s-a mutat în 2025 dinspre algoritmii slabi (care sunt rar greșit în 2026) către greșeli operaționale: chei stocate în repository-uri, chei reutilizate între environments, lipsa de rotație a cheilor, secrete logged accidental în CloudWatch sau Datadog.

Migrare către cryptography post-cuantică este în discuție pentru anumite industrii, dar nu este încă o prioritate practică pentru majoritatea companiilor românești. Ceea ce contează acum este disciplina operațională: folosește un KMS dedicat (AWS KMS, GCP KMS, HashiCorp Vault), rotează chei la intervale clare, nu reutiliza chei între producție și staging și nu loga niciodată secrete chiar dacă sunt mascate parțial.

Echipa Blackbone implementează la clienți un audit lunar de secrete folosind tooling precum TruffleHog, Gitleaks și SOPS pentru gestionarea secretelor în repositories. Un singur secret commit accidental și nedetectat poate compromite ani de muncă; investiția în această disciplină este una dintre cele mai rentabile pe care le poate face un CTO.

03A03:2025 Injection cu focus pe NoSQL și prompt injection

Injection clasică SQL este în continuare prezentă, dar a coborât în prioritate datorită adopției pe scară largă a ORMs și a parametrized queries. Ce a urcat semnificativ în 2025 este NoSQL injection în MongoDB sau DynamoDB (unde dezvoltatorii deseori uită că $where și operatori similari pot fi exploatați) și mai ales prompt injection în aplicații care integrează LLMs.

Prompt injection nu este o categorie OWASP separată încă, dar este referențiată explicit în A03:2025 ca subcategorie. Riscurile reale includ exfiltrare de instrucțiuni sistem, bypass de filtre de moderare, manipularea de outputs către utilizatori finali și mai grav, escaladare prin tools dacă LLM-ul are acces la API-uri interne. Pentru orice produs care expune un LLM către utilizatori finali sau care folosește LLM în pipeline-uri automate, această categorie este critică.

Strategia Blackbone pentru prompt injection are trei nivele: separare clară între system prompt și user input cu delimitatori robuști, validare output cu un LLM secundar pentru cazurile sensibile și principle of least privilege strict pe tools disponibile LLM-ului. Niciun LLM nu ar trebui să aibă acces direct la baze de date sau la API-uri privileged fără o capă de validare umană sau programatică.

04A04:2025 Insecure Design și threat modeling

Insecure design a fost introdus în 2021 ca o categorie distinctă pentru a sublinia că multe vulnerabilități nu sunt bugs implementaționale, ci defecte arhitecturale. În 2025, această categorie capătă greutate suplimentară prin emphasis-ul pe threat modeling formal la fiecare epic semnificativ și pe principle of least privilege la nivel de arhitectură.

Exemple comune de design insecur includ baze de date partajate între tenants fără izolare clară, lipsa de rate limiting pe endpoint-uri critice precum login sau forgot password, autorizare bazată pe parametri trimiși de client în loc de session validation și fluxuri de business care permit operațiuni periculoase fără confirmări secundare.

Echipa Blackbone integrează threat modeling în procesul de discovery al fiecărui epic major folosind framework-ul STRIDE simplificat. Fiecare diagrama de arhitectură vine cu o analiză a fluxurilor de date și a permisiunilor; orice abatere de la principle of least privilege trebuie justificată explicit. Acest proces previne categorii întregi de probleme care altfel ajung descoperite în pentests sau în incidente reale.

05A05:2025 Software Supply Chain Failures și S2C2F

Cea mai semnificativă schimbare în Top 10 2025 este consolidarea unei categorii dedicate supply chain failures, care înlocuiește și extinde Vulnerable and Outdated Components din 2021. Această schimbare reflectă realitatea ultimilor ani: atacuri precum SolarWinds, Log4Shell, dependențe NPM compromise și atacuri pe pipeline-uri CI/CD au demonstrat că supply chain este unul dintre vectorii cei mai exploatați.

Framework-ul S2C2F (Secure Supply Chain Consumption Framework) lansat de Microsoft și integrat în OpenSSF Scorecard oferă un set concret de practici pe care orice CTO ar trebui să le implementeze: verificarea proveniței dependențelor, scanning automat de vulnerabilități în pipeline, separare clară între dependences directe și tranzitive, pinned versions în lockfiles și review-uri obligatorii pentru dependence noi.

Pentru aplicații moderne JavaScript sau Python, recomandarea Blackbone este să folosești Renovate sau Dependabot pentru update-uri automate plus Snyk sau Socket pentru analysis de risc per dependency. Pentru pipeline-uri CI/CD critice, folosește signing-uri SLSA și verifică SBOMs (Software Bill of Materials) la fiecare release. Aceste practici nu sunt opționale în 2026 pentru produse care procesează date sensibile.

• →Pinning de versiuni în lockfiles, niciodată ranges deschise
• →Renovate sau Dependabot pentru update-uri automate controlate
• →Snyk sau Socket pentru risk analysis per dependency
• →SLSA signing pentru artefacts critice de producție
• →SBOMs (Software Bill of Materials) la fiecare release major

06A10:2025 Server-Side Request Forgery în era AI

SSRF a urcat semnificativ în prioritate în 2025 din cauza proliferării de integrări LLM care fac request-uri către resurse externe pe baza unor URL-uri furnizate de utilizatori. Un agent AI care primește un URL spre o pagină web pentru a-l rezuma sau pentru a extrage date poate fi păcălit să acceseze servicii interne, cloud metadata endpoints sau baze de date private.

Cazurile clasice de SSRF rămân relevante: aplicații care fetch imagini din URLs furnizate de useri, webhooks care se conectează la URLs configurate de utilizatori, parsers de feed RSS, conexiuni outbound din pipeline-uri batch. Toate aceste cazuri necesită validare strictă a URL-urilor, denylist de IP-uri interne (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, link-local, cloud metadata 169.254.169.254) și ideal egress proxy care aplică aceste reguli centralizat.

Pentru aplicații cu agenți AI, echipa Blackbone implementează un egress allowlist explicit: agentul poate accesa doar domains aprobate, toate cererile externe trec printr-un proxy care loghează și validează, iar accesul la metadata services cloud este blocat la nivel de network. Această disciplină previne categorii întregi de incidente costisitoare.