Ce înseamnă Security by Design în aplicațiile .NET

  • Doru Bulubasa
  • 25 February 2026

În 2026, securitatea nu mai este un „feature”. Este o proprietate arhitecturală.

Majoritatea aplicațiilor .NET sunt securizate reactiv:

  • adăugăm [Authorize]

  • punem un JWT

  • activăm HTTPS

  • sperăm că este suficient

Dar asta NU este Security by Design.

Security by Design înseamnă:

🔒 Securitatea este gândită din prima zi, la nivel de arhitectură, infrastructură și cod.

🧠 Ce este Security by Design?

Security by Design presupune:

  • identificarea riscurilor înainte de implementare

  • reducerea suprafeței de atac

  • protecții pe mai multe niveluri

  • asumarea faptului că sistemul poate fi compromis

  • monitorizare și audit continuu

Nu este un middleware. Este o mentalitate arhitecturală.


🧩 1. Threat Modeling

Threat modeling înseamnă:

Identificarea modurilor în care aplicația ta poate fi atacată.

Înainte să scrii cod, întreabă-te:

  • Ce date sunt sensibile?

  • Cine are acces la ele?

  • Ce endpoint-uri sunt expuse public?

  • Ce se întâmplă dacă JWT-ul este furat?

  • Ce se întâmplă dacă DB este compromisă?

Un model clasic este STRIDE:

  • Spoofing

  • Tampering

  • Repudiation

  • Information Disclosure

  • Denial of Service

  • Elevation of Privilege

Exemplu real în .NET API:

Ai un endpoint:

[HttpPost("invoice")]
public async Task<IActionResult> CreateInvoice(CreateInvoiceCommand cmd)

Întrebări de threat modeling:

  • Poate un user crea facturi pentru alt CompanyId?

  • Pot modifica payload-ul?

  • Pot trimite cereri masive (DoS)?

  • Pot injecta date periculoase?

Threat modeling = gândire preventivă.


🎯 2. Attack Surface

Attack surface = totalitatea punctelor prin care sistemul poate fi atacat.

Într-o aplicație .NET modernă:

  • API endpoints

  • Swagger UI expus public

  • SignalR hubs

  • Upload fișiere

  • Blazor WASM

  • Admin panel

  • Open ports în infrastructură

Reducerea suprafeței de atac înseamnă:

  • Dezactivezi Swagger în producție

  • Blochezi endpoint-uri nefolosite

  • Dezactivezi detalii de eroare

  • Limitezi CORS

  • Faci rate limiting

Cu cât ai mai puține puncte expuse, cu atât riscul scade.


🛡️ 3. Defense in Depth

Defense in Depth = protecție pe mai multe niveluri.

Nu te bazezi pe un singur mecanism. Exemplu real:

Nivel 1 — HTTPS

Nivel 2 — JWT validat corect

Nivel 3 — Policy-based authorization

Nivel 4 — Validare model

Nivel 5 — Verificare CompanyId în DB

Nivel 6 — Audit log

Dacă un layer cade, altul te protejează.


🧨 4. Zero Trust

Zero Trust înseamnă:

Nu ai încredere în nimic implicit. Nici măcar în interiorul rețelei.

În .NET asta înseamnă:

  • Fiecare request este validat

  • Fiecare claim este verificat

  • Fiecare serviciu verifică token-ul

  • mTLS între servicii

  • Nu există „suntem în VPN deci e sigur”

Zero Trust este standard enterprise în 2026.


⚠️ 5. OWASP Top 10

OWASP publică anual lista celor mai critice vulnerabilități web.

Cele mai relevante pentru aplicații .NET:

  1. Broken Access Control

  2. Cryptographic Failures

  3. Injection

  4. Insecure Design

  5. Security Misconfiguration

  6. Vulnerable Components

  7. Identification & Authentication Failures

  8. Software Integrity Failures

  9. Logging & Monitoring Failures

  10. SSRF

Majoritatea aplicațiilor enterprise pică la:

  • access control

  • misconfiguration

  • logging slab


🔍 Security by Design aplicat concret într-o aplicație .NET

Dacă ai:

  • ASP.NET Core Web API

  • Blazor WebAssembly

  • JWT

  • Integrare externă (ex: e-Factura)

  • Certificate X509

Security by Design ar însemna:

✅ JWT cu cheie asimetrică

✅ Refresh token rotation

✅ Policy-based authorization

✅ Validare strictă CompanyId

✅ Audit log pentru fiecare acțiune critică

✅ Rate limiting

✅ mTLS pentru integrare externă

✅ Certificate validate corect (CRL / chain)

✅ Logging centralizat

Nu doar „merge”. Ci:

este defensiv construit.

🔥 Greșeli frecvente în aplicațiile .NET

  1. JWT cu secret hardcodat

  2. Fără expirare token

  3. Doar role-based authorization

  4. Lipsă audit log

  5. Returnarea excepțiilor complete în producție

  6. Fără rate limiting

  7. Fără validare model

  8. Acceptarea oricărui certificat client


🧱 Checklist de Security by Design pentru .NET

  • HTTPS forțat

  • HSTS activ

  • JWT validare corectă

  • Refresh tokens securizate

  • Authorization pe policy

  • Input validation

  • Anti-forgery unde e cazul

  • Rate limiting

  • Logging securizat

  • Monitorizare anomalii

  • Dependency scanning

  • Secrets în Azure Key Vault / env vars


🎯 Concluzie

Security by Design nu înseamnă:

„Punem un JWT și suntem gata.”

Înseamnă:

Construim aplicația ca și cum cineva încearcă deja să o spargă.

🤖 Întreabă AI despre acest articol

Răspuns generat de AI pe baza acestui articol.
AI scrie răspunsul…

Scrie un comentariu

Adresa de mail nu va fi publicata. Campurile obligatorii sunt marcate cu *