Securitate și protecția datelor

Autentificare

	Clienți	Echipa
Factor 1	e-mail + parolă (bcrypt, cost 12, peste un SHA-256 al parolei, ca toate cele 128 de caractere permise să conteze; sare unică, comparare în timp constant)	e-mail + parolă
Factor 2	TOTP opțional, activat din Setări (confirmat cu un cod); suportul îl poate dezactiva pentru un telefon pierdut (auditat, clientul anunțat)	TOTP obligatoriu (RFC 6238, aplicație de autentificare); configurat prin QR la prima conectare
Sesiune	cookie HttpOnly, SameSite=Lax, Secure în producție; sesiune în baza de date (doar hash-ul SHA-256 al tokenului), glisantă, 30 de zile	cookie separat, 12 ore; dispozitiv de încredere opțional, 30 de zile
Limitare	5 încercări eșuate → contul (e-mailul) blocat 15 minute; 5 coduri greșite închid pasul al doilea	la fel; codurile TOTP sunt de unică folosință (nu pot fi refolosite)
Deconectare forțată	la schimbarea parolei (celelalte sesiuni), la suspendare, la ștergerea contului	la dezactivare și la resetarea TOTP

Politica parolelor: minim 8 caractere, litere și cifre, nu dintre parolele comune, nu conține numele din e-mail. Linkurile de resetare, confirmare și invitație sunt de unică folosință, cu expirare, stocate ca amprentă SHA-256.

Autorizare

• Clienții accesează doar propriile resurse: fiecare serviciu verifică proprietarul (o comandă a altcuiva întoarce NOT_FOUND, nu FORBIDDEN, ca să nu dezvăluie existența ei).
• Echipa: permisiuni pe rol, verificate de StaffAuthGuard pe fiecare operație (@RequirePermissions). Meniul ascunde doar ce nu se poate folosi; protecția reală e în API. Vezi rolurile.
• Reguli de protecție a echipei: nimeni nu își schimbă singur rolul sau accesul; ultimul administrator activ nu poate fi eliminat.

Date personale (GDPR)

Principiu	Cum e aplicat
Minimizare	actele de identitate se șterg la decizie; fotografiile pierd metadatele (inclusiv GPS); datele cardului nu se primesc pe server dincolo de verificare și nu se stochează niciodată (doar marca și ultimele 4 cifre)
Transparență și acces	exportul complet al datelor (JSON) din Setări
Ștergere	anonimizare: e-mail, nume, telefon, IBAN, avatar dispar; anunțurile se scot; acordurile se retrag cu dovadă; istoricul comenzilor rămâne coerent pentru ceilalți și pentru contabilitate
Acord	marketing doar cu acord explicit pe canal; fiecare schimbare e o dovadă (sursă, IP, moment) în consent_events, care doar se adaugă
Dreptul de opoziție	link de dezabonare în fiecare e-mail (semnat HMAC, inclusiv one-click), răspuns STOP la SMS, setări în cont
Acces intern	datele sensibile (acte) cer permisiune dedicată; vizualizarea e auditată; IBAN-ul apare doar mascat

Aplicația

• Injecție SQL: interogările trec prin ORM sau sunt parametrizate; regulile segmentelor CRM sunt traduse prin listă albă de câmpuri și operatori.
• XSS: React escapează tot textul; conținutul HTML static (pagini informative) e al nostru, nu al utilizatorilor.
• CSRF: cookie SameSite=Lax, API pe același domeniu și protecția CSRF implicită a Apollo Server (cererile „simple” fără antet JSON sunt refuzate).
• Validare: fiecare câmp de intrare GraphQL are reguli class-validator; build-ul verifică asta (check:inputs), iar whitelist elimină câmpurile necunoscute.
• Fișiere: orice imagine e decodată și re-encodată (un fișier care nu e imagine e refuzat); limită de dimensiune și de pixeli.
• Erori: în producție, erorile neașteptate nu dezvăluie detalii (doar „Internal server error”).
• Dependențe: pnpm instalează doar versiuni publicate de cel puțin 14 zile; scripturile de instalare sunt blocate implicit.

Infrastructură

• Doar containerele site, Backoffice și CRM sunt expuse; API-ul, MySQL și fișierele încărcate rămân în rețeaua internă. Pe cPanel, rădăcina web a API-ului e doar folderul public/; codul, .env și storage/ nu sunt accesibile din web.
• În producție: HTTPS obligatoriu (COOKIE_SECURE=true), APP_DEBUG=false, DIAGNOSTICS_ENABLED=false, SEED_DEMO_DATA=false, secrete generate aleator (APP_KEY, parolele bazelor de date).
• Antete de securitate din nginx: Content-Security-Policy (scripturi doar de pe propriul domeniu), X-Content-Type-Options, Referrer-Policy, X-Frame-Options: DENY, Permissions-Policy.

Audit

Fiecare acțiune a echipei cu efect asupra clienților sau a banilor e înregistrată în audit_logs: cine, ce, asupra cui, detalii (de exemplu valoarea veche și nouă a unei setări, suma unei rambursări). Jurnalul se vede în Backoffice → Echipă și audit.