Protecție împotriva atacurilor

Măsurile concrete împotriva injectărilor, XSS-ului, CSRF-ului, abuzului de trafic și datelor malițioase.

Securitatea în Recash nu este un singur zid, ci mai multe straturi, fiecare acoperind o categorie cunoscută de risc. Dacă unul cedează, următorul încă ține:

injectare — identificatori validați strict, interogări parametrizate
XSS — randare controlată, fără HTML injectat
CSRF — protecție nativă și cookie-uri restrictive
abuz de trafic — limitarea numărului de cereri, per utilizator sau per IP
date malițioase — validare pe fiecare formular
acțiuni nepermise — verificări de proprietate și de concurență pe fiecare operație

Injectare în baza de date

Identificatori validați strict

Orice identificator primit de la client și folosit într-o interogare este verificat mai întâi printr-un format strict — trebuie să arate exact ca un identificator valid al bazei de date, altfel cererea este respinsă imediat, înainte de orice atingere a bazei. Un identificator „aproape corect”, cu caractere în plus sau simboluri strecurate, nu ajunge niciodată la interogare.

Interogări parametrizate

Dincolo de validare, accesul la baza de date trece exclusiv prin Prisma, care parametrizează intern toate interogările: valorile venite de la utilizator sunt trimise separat de structura interogării, niciodată lipite în text. Nicăieri în cod nu se construiește manual o interogare din text primit de la client — condiția de bază pentru a face injectarea imposibilă, nu doar improbabilă.

Cross-site scripting (XSS)

React modifică automat orice text randat în interfață, așa că un <script> introdus într-un câmp ajunge pe ecran ca text inofensiv, nu ca și cod executat. Codul nu folosește nicăieri inserarea de HTML brut în pagină, singura poartă prin care ar putea trece conținut executabil.

Protecție CSRF nativă

Fluxul de autentificare gestionează nativ protecția împotriva atacurilor cross-site request forgery pe rutele sensibile, prin token-uri anti-CSRF verificate la fiecare cerere care schimbă starea. O pagină străină nu poate declanșa acțiuni în numele unui utilizator autentificat doar pentru că acesta are un cookie valid.

Cookie-ul de sesiune este configurat defensiv: inaccesibil din JavaScript (httpOnly, deci nu poate fi furat de un script), trimis doar pe același loc (sameSite) și doar prin conexiune securizată în producție, cu prefixul __Secure- care interzice browserului să-l accepte pe HTTP. Un cookie de sesiune nu poate fi nici citit de cod străin, nici trimis dintr-un context terț.

Limitarea traficului

Fereastră glisantă în Redis

Fiecare cerere trece printr-un limitator care numără, în Redis, câte cereri a făcut același solicitant în ultimul interval de timp. Momentul fiecărei cereri este înregistrat exact, iar cererile mai vechi decât fereastra ies automat din calcul — limita se raportează astfel mereu la intervalul imediat precedent și nu poate fi ocolită prin rafale trimise fix la granița dintre două intervale.

Praguri per rută

Identificarea depinde de tipul rutei: pe rutele autentificate, limita se aplică per cont de utilizator; pe cele publice, per adresă IP. Pragurile diferă după cât de costisitoare este ruta — citirile au limite permisive, scrierile sunt mai stricte, iar analiza AI, cea mai costisitoare operație, este cea mai restricționată. La depășire, aplicația răspunde cu 429 și un antet care spune peste cât timp se poate reîncerca, nu cu o eroare de server. Distincția și motivația din spate sunt detaliate în Scalabilitate & performanță.

Ce se întâmplă dacă Redis nu răspunde

Dacă limitatorul însuși nu poate fi contactat, cererea este lăsată să treacă, nu blocată — o alegere deliberată de a păstra aplicația funcțională în fața unei defecțiuni de infrastructură, în loc să transforme o problemă la Redis într-o pană totală.

Validarea datelor de intrare

Limite pe fiecare câmp

Fiecare formular trece printr-o schemă de validare înainte să ajungă la logica aplicației, iar orice câmp are limite explicite: numărul de sticle este un întreg într-un interval rezonabil, valoarea garanției trebuie să fie pozitivă și sub un plafon, procentul împărțit stă între 0 și 100, coordonatele geografice în limitele reale ale globului, iar adresele de imagini trebuie să fie URL-uri valide, limitate ca număr. Un payload care nu respectă schema este respins cu un mesaj clar, nu strecurat mai departe.

Regula anti-contact

Descrierea unei postări nu poate conține numere de telefon, adrese de email sau linkuri. Această regulă nu este doar una tehnică, ci o măsură de siguranță pentru utilizatori: previne mutarea tranzacției în afara platformei — unde există rating, istoric și protecție — către un canal privat, unde riscul de fraudă crește pentru ambele părți.

Apărare pe mai multe niveluri

Protecția nu depinde de un singur punct de control — mai multe verificări independente se aplică simultan asupra aceleiași acțiuni.

Filtru, verificare, reguli de business

Middleware-ul de la marginea aplicației, verificarea de sesiune din fiecare rută și regulile aplicației se aplică toate, în lanț. Autentificarea confirmă cine ești; autorizarea pe obiect confirmă dreptul tău asupra acelui obiect anume — doar autorul își anulează postarea, doar participanții văd codul unei colectări. O verificare care trece nu o scutește pe următoarea.

Concurență optimistă

Operațiile care schimbă starea nu presupun că nimic nu s-a schimbat între citire și scriere. Actualizarea se face condiționat — doar dacă postarea este încă în starea așteptată — iar dacă între timp altcineva a modificat-o, operația eșuează controlat cu 409, în loc să suprascrie orbește. Așa sunt prevenite dublările și cursele: două cereri simultane nu pot revendica sau finaliza de două ori aceeași colectare.

Cod de confirmare unic

Finalizarea unei colectări cere un cod de confirmare de unică folosință, ținut separat în Redis și accesibil doar participanților. Predarea nu poate fi marcată drept încheiată fără codul deținut de cealaltă parte.

Tratarea sigură a erorilor

Când ceva neprevăzut eșuează pe server, clientul primește un mesaj generic și un cod de eroare, niciodată detalii interne — urme de stivă, interogări sau structura bazei de date. Informația utilă pentru depanare rămâne în jurnalele de pe server, unde ajută dezvoltatorii, nu un eventual atacator care caută indicii despre cum e construită aplicația.