Kako dodati kontrolu pristupa zasnovanu na ulogama (RBAC) u aplikaciju

Da biste dodali kontrolu pristupa po ulogama, svakom korisniku dodijelite jednu ili više uloga (na primjer administrator, urednik, čitalac), definišite koje radnje svaka uloga smije obavljati i provjerite te dozvole na serveru za svaki zahtjev — ne samo sakrivanjem dugmadi. Također provjerite da zapis kojem se pristupa pripada korisnikovom nalogu ili timu. Počnite s nekoliko fiksnih uloga u bazi podataka i testirajte tako što ćete direktno pokušati pristupiti tuđim podacima.

Autentifikacija i autorizacija

Dvije riječi koje se često miješaju:

• Autentifikacija je ko si ti? — prijava. Pogledajte kako dodati prijavu u aplikaciju.
• Autorizacija je šta smiješ da radiš? — koje stranice, zapise i radnje prijavljeni korisnik može dosegnuti.

RBAC je najčešći način autorizacije. To je važno: od septembra 2026. Broken Access Control je na prvom mjestu u OWASP Top 10:2025, široko korišćenoj listi najozbiljnijih rizika za sigurnost web aplikacija. Tipični propusti su korisnici koji čitaju tuđe zapise mijenjajući ID u URL-u ili obični korisnici koji pozivaju API rute namijenjene samo administratorima.

Izaberite model

U praksi većina aplikacija kombinuje dvije stvari: uloge za to kakve radnje neko može preduzeti i vlasništvo za to nad kojim zapisima ih može preduzeti. „Urednici mogu uređivati postove“ je pravilo o ulozi; „…postove u svom radnom prostoru“ je pravilo o vlasništvu. Trebate oboje.

Počnite jednostavnije nego što mislite. Administrator, član i čitalac pokrivaju iznenađujuće mnogo aplikacija. Lakše je kasnije podijeliti ulogu nego raspetljati deset uloga koje niko ne razumije.

Osmislite uloge prije pisanja koda

Prvo napišite tabelu dozvola običnim jezikom. Ona služi kao specifikacija za AI i kao plan testiranja:

Odlučite i rubne slučajeve: može li posljednji vlasnik napustiti tim? Može li administrator ukloniti vlasnika? Šta vidi uklonjen korisnik?

Korak po korak

1. Prvo imajte ispravnu prijavu

RBAC leži iznad autentifikacije. Server mora pouzdano znati ko šalje svaki zahtjev, iz sesije ili provjerenog tokena — nikad iz ID-ja korisnika koji browser pošalje u tijelu zahtjeva.

2. Čuvajte uloge u bazi podataka

Za aplikaciju s jednim timom, kolona role na korisnicima je dovoljna. Za timove koristite tabelu članstava:

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)
);

Nikad nemojte dozvoliti korisnicima da sami postave svoju ulogu kroz običnu izmjenu profila. Promjene uloga idu kroz posebnu krajnju tačku koja provjerava dozvole.

3. Provjeravajte dozvole na serveru, na jednom mjestu

Napišite jednu pomoćnu funkciju — nešto poput can(user, 'projects.delete', project) — i pozivajte je u svakoj API ruti, serverskoj akciji i pozadinskom zadatku koji čita ili mijenja podatke. Jedna centralna funkcija se lakše pregleda i testira nego provjere razbacane po kodu. Podrazumijevano odbijte: ako nijedno pravilo ne dozvoljava radnju, ona se odbija.

4. Ograničite svaki upit

Svaki upit za podatke tima treba uključivati tim: where organization_id = :currentOrg, a ne samo where id = :id. Upravo to sprječava da neko promijeni /projects/123 u /projects/124 i vidi projekat druge kompanije. Za zapise iz drugih timova vraćajte „nije pronađeno“ umjesto „zabranjeno“, da ne otkrijete da postoje.

5. Dodajte zaštitu na nivou baze tamo gdje je važna

Postgres row-level security (RLS) omogućava bazi da provodi koje redove svaki korisnik može vidjeti. Ona je neophodna ako browser direktno komunicira s bazom (kao kod nekih hostovanih backenda), a inače je koristan drugi sloj za osjetljive tabele.

6. Odražavajte uloge u sučelju

Sada sakrijte ili onemogućite ono što korisnici ne smiju raditi, da aplikacija ne bude zbunjujuća. Ovo služi samo upotrebljivosti; zaštitu obavljaju provjere na serveru.

7. Bilježite osjetljive radnje

Zapisujte ko je mijenjao uloge, brisao podatke ili izvozio zapise, i kada. Zapisnik revizije pomaže kod pitanja podrške i incidenata.

8. Testirajte kao napadač

Prijavite se kao svaka uloga i isprobajte svaku radnju iz tabele dozvola. Zatim isprobajte stvari koje ne bi smjele raditi: pozovite API rute administratora kao čitalac, mijenjajte ID-jeve u URL-ovima i zahtjevima, uklonite sebe kao posljednjeg vlasnika. Automatizovani testovi za tabelu dozvola vrijedi napisati kad se pravila slegnu.

Upiti koji rade

Dodaj kontrolu pristupa po ulogama. Uloge po organizaciji: owner, admin, member, viewer, pohranjene u tabeli memberships. Dozvole su u ovoj tabeli: [nalijepi svoju tabelu]. Napravi jednu serversku pomoćnu funkciju can(user, action, resource), podrazumijevano odbijanje, i koristi je u svakoj API ruti. Ograniči svaki upit na organization_id. Sakrij radnje koje korisnik ne može obaviti u sučelju, ali se za sigurnost nikad ne oslanjaj na to.

Pregledaj svaku API rutu i serversku funkciju u ovoj aplikaciji. Za svaku navedi koje podatke čita ili mijenja, provjerava li da je korisnik prijavljen, provjerava li njegovu ulogu i ograničava li upit na njegovu organizaciju. Popravi one kojima nedostaje provjera i pokaži mi listu.

Dodaj stranicu /admin samo za vlasnika gdje vlasnik može mijenjati uloge članova. Spriječi uklanjanje ili degradiranje posljednjeg vlasnika, zabilježi svaku promjenu uloge uz to ko ju je napravio i kada, i osiguraj da krajnja tačka za promjenu uloga odbija svakoga ko nije vlasnik.

Česte greške

• Provjera uloga samo u frontendu. API je i dalje otvoren za svakoga ko ga pozove.
• Vjerovanje ID-jevima sa klijenta — userId ili role u tijelu zahtjeva umjesto u sesiji.
• Neograničeni upiti koji dohvataju po samo ID-ju zapisa.
• Uloge provjerene na stranicama, ali ne na API rutama, izvozima, preuzimanjima fajlova ili webhookovima.
• Administrator po adresi e-pošte zapisanoj direktno u kodu (if email === 'me@...'), što je lako zaboraviti i teško promijeniti.
• Previše uloga prerano, koje niko ne može objasniti šest mjeseci kasnije.
• Zastarjele sesije: degradirani korisnik zadržava administratorska prava dok se ne odjavi. Na osjetljivim radnjama provjeravajte uloge iz baze ili ih osvježavajte.

Kontrolna lista RBAC-a

• Tabela dozvola napisana običnim jezikom, rubni slučajevi odlučeni
• Server zna korisnika iz sesije, nikad iz podataka zahtjeva
• Uloge su u bazi podataka; korisnici ne mogu mijenjati svoje
• Jedna centralna provjera dozvola, podrazumijevano odbijanje, korištena u svakoj ruti
• Svaki upit ograničen na korisnikovu organizaciju ili vlasništvo
• Row-level security tamo gdje browser može doći do baze
• Sučelje sakriva ono što korisnici ne mogu raditi (samo radi upotrebljivosti)
• Osjetljive radnje se bilježe
• Svaka uloga testirana, uključujući direktne API pozive i promijenjene ID-jeve

Kontrola pristupa je jedna stavka na dužoj listi; kontrolna lista sigurnosti za aplikacije napravljene uz AI pokriva ostalo. Ako pravite alat za vlastito osoblje, kako napraviti interni alat pokazuje gdje se uklapaju uloge.

RBAC na Mythexu

Mythex ne pruža ugrađeni sistem prijave ili uloga za korisnike vaše aplikacije. Vi birate biblioteku ili pružaoca autentifikacije i opišete uloge, a agent ih povezuje u vaš kod i u Postgres bazu vašeg projekta (dodavanje prijave u aplikaciju). Mythexove vlastite uloge u radnom prostoru, kao što su Owner i Member, kontrolišu ko može uređivati vaše Mythex projekte, a ne ko može koristiti aplikaciju koju objavite. Koristite Plan mode da se dogovorite o tabeli dozvola prije izrade, zatim koristite gornji upit za pregled i testirajte svaku ulogu u pregledu prije objavljivanja. Korisni nastavak su sigurnosni upiti iz dokumentacije.

Pitanja