Cum adaugi control al accesului pe bază de roluri (RBAC) în aplicația ta

Pentru a adăuga control al accesului pe bază de roluri, dă fiecărui utilizator unul sau mai multe roluri (de exemplu admin, editor, viewer), definește ce acțiuni poate face fiecare rol și verifică acele permisiuni pe server pentru fiecare cerere — nu doar ascunzând butoane. Verifică și că înregistrarea accesată aparține contului sau echipei utilizatorului. Începe cu câteva roluri fixe în baza ta de date și testează încercând să ajungi direct la datele altui utilizator.

Autentificare vs autorizare

Două cuvinte care se confundă des:

• Autentificarea este cine ești? — conectarea. Vezi cum adaugi autentificare în aplicația ta.
• Autorizarea este ce ai voie să faci? — ce pagini, înregistrări și acțiuni poate atinge un utilizator conectat.

RBAC este cel mai comun mod de a face autorizare. Contează: din septembrie 2026, Broken Access Control este pe locul #1 în OWASP Top 10:2025, lista larg folosită a celor mai serioase riscuri de securitate ale aplicațiilor web. Erorile tipice sunt utilizatorii care citesc înregistrările altora schimbând un ID în URL sau utilizatorii obișnuiți care apelează rute API rezervate adminilor.

Alege un model

În practică, majoritatea aplicațiilor combină două lucruri: roluri pentru ce fel de acțiuni poate face cineva și proprietate pentru asupra cărror înregistrări le poate face. „Editorii pot edita postările” este o regulă de rol; „…postările din spațiul lor de lucru” este o regulă de proprietate. Ai nevoie de amândouă.

Începe mai simplu decât crezi. Admin, membru și viewer acoperă un număr surprinzător de aplicații. Este mai ușor să împarți un rol mai târziu decât să descâlcești zece roluri pe care nimeni nu le înțelege.

Definește rolurile înainte să scrii cod

Scrie întâi un tabel de permisiuni în limbaj simplu. Servește ca specificație pentru AI și ca plan de testare:

Decide și cazurile limită: poate ultimul proprietar să plece? Poate un admin să îl elimine pe proprietar? Ce vede un utilizator eliminat?

Pas cu pas

1. Ai întâi un login care funcționează

RBAC stă deasupra autentificării. Serverul trebuie să știe sigur cine face fiecare cerere, dintr-o sesiune sau dintr-un token verificat — niciodată dintr-un ID de utilizator pe care îl trimite browserul în corpul cererii.

2. Stochează rolurile în baza de date

Pentru o aplicație cu o singură echipă, o coloană role pe utilizatori este suficientă. Pentru echipe, folosește un tabel de membrii:

create table memberships (
  user_id uuid references users(id),
  organization_id uuid references organizations(id),
  role text not null check (role in ('owner','admin','member','viewer')),
  primary key (user_id, organization_id)
);

Nu lăsa niciodată utilizatorii să își seteze singuri rolul printr-o actualizare obișnuită a profilului. Schimbările de rol trec printr-un endpoint dedicat, verificat după permisiuni.

3. Verifică permisiunile pe server, într-un singur loc

Scrie un helper — ceva de genul can(user, 'projects.delete', project) — și apelează-l în fiecare rută API, server action și job în fundal care citește sau modifică date. O funcție centrală este mai ușor de revizuit și de testat decât verificările împrăștiate prin cod. Refuz implicit: dacă nicio regulă nu permite o acțiune, ea este refuzată.

4. Limitează fiecare interogare

Fiecare interogare pentru datele echipei ar trebui să includă echipa: where organization_id = :currentOrg, nu doar where id = :id. Asta oprește pe cineva să schimbe /projects/123 în /projects/124 și să vadă proiectul altei companii. Returnează „not found” în loc de „forbidden” pentru înregistrările din alte echipe, ca să nu dezvălui că există.

5. Adaugă protecție la nivelul bazei de date acolo unde contează

Row-level security (RLS) din Postgres lasă baza de date să aplice ce rânduri poate vedea fiecare utilizator. Este esențială dacă browserul vorbește direct cu baza de date (ca în unele backend-uri găzduite) și un strat util suplimentar pentru tabelele sensibile în rest.

6. Reflectă rolurile în interfață

Acum ascunde sau dezactivează ce nu pot face utilizatorii, ca aplicația să nu fie confuză. Asta este doar pentru utilizabilitate; verificările de pe server sunt cele care protejează.

7. Jurnalizează acțiunile sensibile

Înregistrează cine a schimbat roluri, a șters date sau a exportat înregistrări și când. Un jurnal de audit ajută cu întrebările de suport și cu incidentele.

8. Testează ca un atacator

Autentifică-te ca fiecare rol și încearcă fiecare acțiune din tabelul de permisiuni. Apoi încearcă lucrurile care nu ar trebui să funcționeze: apelează rute API de admin ca viewer, schimbă ID-urile din URL-uri și cereri, elimină-te ca ultim proprietar. Merită scris teste automate pentru tabelul de permisiuni, odată ce regulile sunt stabile.

Prompturi care funcționează

Adaugă control al accesului pe bază de roluri. Roluri pe organizație: owner, admin, member, viewer, stocate într-un tabel memberships. Permisiunile sunt în acest tabel: [lipește tabelul tău]. Creează un singur helper de server can(user, action, resource), cu refuz implicit, și folosește-l în fiecare rută API. Limitează fiecare interogare după organization_id. Ascunde în interfață acțiunile pe care utilizatorul nu le poate face, dar nu te baza niciodată pe asta pentru securitate.

Revizuiește fiecare rută API și funcție de server din această aplicație. Pentru fiecare, listează ce date citește sau modifică, dacă verifică că utilizatorul este conectat, dacă verifică rolul lui și dacă limitează interogarea la organizația lui. Repară pe cele care nu au o verificare și arată-mi lista.

Adaugă o pagină /admin doar pentru admini, unde proprietarul poate schimba rolurile membrilor. Împiedică eliminarea sau retrogradarea ultimului proprietar, jurnalizează fiecare schimbare de rol cu cine a făcut-o și când și asigură-te că endpoint-ul de schimbare a rolului respinge pe oricine nu este proprietar.

Greșeli frecvente

• Verificarea rolurilor doar în frontend. API-ul rămâne deschis oricui îl apelează.
• Încrederea în ID-uri venite de la client — un userId sau role în corpul cererii în loc de sesiune.
• Interogări nelimitate care aduc înregistrări doar după ID-ul lor.
• Roluri verificate pe pagini, dar nu pe rutele API, exporturi, descărcări de fișiere sau webhook-uri.
• Admin după adresa de email, scris direct în cod (if email === 'me@...'), ușor de uitat și greu de schimbat.
• Prea multe roluri de la început, pe care nimeni nu le mai poate explica după șase luni.
• Sesiuni vechi: un utilizator retrogradat păstrează drepturi de admin până se deconectează. Verifică rolurile din baza de date sau împrospătează-le la acțiunile sensibile.

Lista de verificare RBAC

• Tabel de permisiuni scris în limbaj simplu, cazurile limită decise
• Serverul știe utilizatorul din sesiune, niciodată din datele cererii
• Roluri stocate în baza de date; utilizatorii nu își pot schimba singuri rolul
• O singură verificare centrală de permisiuni, cu refuz implicit, folosită în fiecare rută
• Fiecare interogare limitată la organizația sau proprietatea utilizatorului
• Row-level security acolo unde browserul poate ajunge la baza de date
• Interfața ascunde ce nu pot face utilizatorii (doar pentru utilizabilitate)
• Acțiunile sensibile jurnalizate
• Fiecare rol testat, inclusiv apeluri API directe și ID-uri schimbate

Controlul accesului este un punct dintr-o listă mai lungă; lista de verificare de securitate pentru aplicațiile construite cu AI acoperă restul. Dacă construiești un instrument pentru personalul tău, cum construiești un instrument intern arată unde se potrivesc rolurile.

RBAC pe Mythex

Mythex nu oferă un sistem încorporat de login sau de roluri pentru utilizatorii aplicației tale. Alegi o bibliotecă sau un furnizor de autentificare și descrii rolurile, iar agentul le conectează în codul tău și în baza de date Postgres a proiectului (adaugă login în aplicația ta). Rolurile de spațiu de lucru ale Mythex, precum Owner și Member, controlează cine poate edita proiectele tale Mythex, nu cine poate folosi aplicația publicată. Folosește modul Plan ca să stabiliți tabelul de permisiuni înainte să construiești, apoi folosește promptul de revizuire de mai sus și testează fiecare rol în Preview înainte să publici. Prompturile de securitate din documentație sunt un pas următor util.

Întrebări