Ce e autorizarea ruptă și IDOR

Controlul accesului rupt înseamnă că aplicația ta lasă un utilizator să facă sau să vadă ceva ce nu ar trebui. Nu e o spargere sofisticată, e o verificare care lipsește. E riscul numărul unu din OWASP Top 10 2025, iar în aplicațiile generate cu AI apare mai des decât orice altceva. Această lecție îl explică de la cap la coadă, cu un exemplu pe care îl poți urmări.

Două întrebări diferite: cine ești și ce ai voie

Orice aplicație care are conturi răspunde, de fapt, la două întrebări separate. Prima e autentificarea: cine ești tu, dovedit prin parolă, cod sau un provider de login. A doua e autorizarea: ce ai voie să faci și ce date ai voie să vezi, odată ce știm cine ești. Sunt lucruri diferite, iar codul le tratează în locuri diferite.

Autorizarea ruptă e când a doua verificare lipsește sau e greșită. Ești un utilizator autentificat perfect valid, dar aplicația îți dă acces la ceva ce aparține altcuiva, pentru că nimeni nu a verificat că acel ceva e chiar al tău. Te-ai logat cinstit, apoi ai deschis o ușă care trebuia să fie a altcuiva.

IDOR, pe scurt

Cea mai comună formă se numește IDOR, prescurtare de la Insecure Direct Object Reference, adică referință directă și nesigură la un obiect. Sună tehnic, dar ideea e simplă: aplicația servește o resursă după un identificator din cerere, fără să verifice dacă tu ai voie să vezi acea resursă.

Imaginează-ți o aplicație de facturare. Factura ta se deschide la o adresă de forma /api/facturi/1042. Numărul 1042 e identificatorul facturii tale. Ce se întâmplă dacă schimbi manual, în bara de adrese, 1042 în 1043? Dacă serverul îți întoarce factura cu numărul 1043, chiar dacă ea aparține unui alt client, ai găsit un IDOR. Un singur caracter schimbat, iar tu vezi datele altcuiva. Nu ai spart nimic. Ai cerut politicos, iar serverul a răspuns fără să verifice.

De ce e atât de periculos

Pentru că e trivial de exploatat și greu de observat. Identificatorii sunt adesea numere care cresc în ordine: 1042, 1043, 1044. Cine găsește tiparul poate parcurge tot, de la primul la ultimul, cu un script simplu. Nu are nevoie de unelte speciale, doar de un browser și de curiozitate. Iar din partea ta, totul pare că funcționează, pentru că aplicația chiar întoarce date. Doar că le întoarce oricui.

Cazurile reale arată exact asta. La McHire, platforma de recrutare a McDonald's operată de Paradox.ai, doi cercetători au intrat pe un cont de test de administrator lăsat cu parola implicită, apoi o referință nesigură în API dădea acces la datele oricărui candidat. Impactul potențial: peste 60 de milioane de candidați. La TeaOnHer, o aplicație verificată de TechCrunch, API-ul întorcea datele altor utilizatori, iar imaginile actelor de identitate stăteau la adrese accesibile. Aceeași familie de greșeală, de fiecare dată: o resursă servită fără verificarea că cel care o cere are voie să o vadă.

Unde intră asta în cadrul mare

În OWASP Top 10 2025, lista de referință a riscurilor web, categoria A01 se numește Broken Access Control, controlul accesului rupt, și e pe primul loc. IDOR e forma ei cea mai des întâlnită în aplicațiile mici. Restul cursului îți arată de ce apare atât de des în codul generat de AI, unde trebuie făcută verificarea și cum scrii un pattern corect pe care să îl refolosești peste tot.

De reținut

• Autentificarea spune cine ești; autorizarea spune ce ai voie. Autorizarea ruptă e a doua verificare lipsă sau greșită.
• IDOR: aplicația servește o resursă după un id din cerere, fără să verifice dacă utilizatorul are voie să o vadă.
• E trivial de exploatat, mai ales cu id-uri secvențiale, și greu de observat, pentru că aplicația pare că funcționează.
• Aceeași verificare de proprietar e obligatorie la citire, la scriere și la ștergere, nu doar la citire.