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

Da biste dodali kontrolu pristupa zasnovanu na ulogama, dajte svakom korisniku jednu ili više uloga (na primer administrator, urednik, posmatrač), definišite koje radnje svaka uloga sme da obavlja i proveravajte te dozvole na serveru za svaki zahtev — ne samo sakrivanjem dugmadi. Takođe proverite da zapis kojem se pristupa pripada nalogu ili timu korisnika. Počnite sa nekoliko fiksnih uloga u bazi i testirajte pokušajem da direktno dođete do tuđih podataka.

Autentifikacija i autorizacija

Dve reči koje se često mešaju:

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

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

Izaberite model

U praksi, većina aplikacija kombinuje dve stvari: uloge za to kakve radnje neko može da preduzme i vlasništvo za to nad kojim zapisima ih može preduzeti. „Urednici mogu da menjaju postove” je pravilo uloge; „…postove u svom radnom prostoru” je pravilo vlasništva. Potrebna su vam oba.

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

Osmislite uloge pre pisanja koda

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

Odlučite i granične slučajeve: može li poslednji vlasnik da napusti tim? Može li administrator da ukloni vlasnika? Šta uklonjeni korisnik vidi?

Korak po korak

1. Prvo imajte ispravnu prijavu

RBAC leži na vrhu autentifikacije. Server mora pouzdano da zna ko šalje svaki zahtev, iz sesije ili proverenog tokena — nikada iz ID-ja korisnika koji pregledač pošalje u telu zahteva.

2. Čuvajte uloge u bazi

Za aplikaciju jednog tima, kolona role na korisnicima je dovoljna. Za timove, koristite tabelu članstva:

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

Nikada ne dozvolite korisnicima da sami postave svoju ulogu kroz običnu izmenu profila. Promene uloga idu kroz posebnu krajnju tačku sa proverom dozvola.

3. Proveravajte dozvole na serveru, na jednom mestu

Napišite jednu pomoćnu funkciju — nešto kao can(user, 'projects.delete', project) — i pozovite je u svakoj API ruti, serverskoj akciji i pozadinskom zadatku koji čita ili menja podatke. Jedna centralna funkcija se lakše pregleda i testira nego provere raštrkane po kodu. Podrazumevano odbijajte: ako nijedno pravilo ne dozvoljava radnju, ona se odbija.

4. Ograničite svaki upit

Svaki upit za podatke tima treba da uključuje tim: where organization_id = :currentOrg, a ne samo where id = :id. Ovo sprečava da neko promeni /projects/123 u /projects/124 i vidi tuđi projekat druge kompanije. Za zapise iz drugih timova vraćajte „nije pronađeno” umesto „zabranjeno”, da ne biste otkrili da postoje.

5. Dodajte zaštitu na nivou baze tamo gde je bitna

Postgres row-level security (RLS) omogućava bazi da sprovodi koje redove svaki korisnik može da vidi. Ključna je ako pregledač direktno komunicira sa bazom (kao kod nekih hostovanih backend-a), a inače je koristan drugi sloj za osetljive tabele.

6. Odrazite uloge u interfejsu

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

7. Beležite osetljive radnje

Zapisujte ko je menjao 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 ono što ne bi trebalo da radi: pozovite administrativne API rute kao posmatrač, menjajte ID-jeve u URL-ovima i zahtevima, uklonite sebe kao poslednjeg vlasnika. Automatizovani testovi za tabelu dozvola vredi napisati kada se pravila ustale.

Prompt-ovi koji rade

Dodajte kontrolu pristupa zasnovanu na ulogama. Uloge po organizaciji: owner, admin, member, viewer, sačuvane u tabeli memberships. Dozvole su u ovoj tabeli: [nalepite svoju tabelu]. Napravite jednu serversku funkciju can(user, action, resource), podrazumevano odbijanje, i koristite je u svakoj API ruti. Ograničite svaki upit sa organization_id. Sakrijte u interfejsu radnje koje korisnik ne može da obavi, ali se za bezbednost nikada ne oslanjajte na to.

Pregledajte svaku API rutu i serversku funkciju u ovoj aplikaciji. Za svaku navedite koje podatke čita ili menja, da li proverava da je korisnik prijavljen, da li proverava njegovu ulogu i da li ograničava upit na njegovu organizaciju. Ispravite sve kojima nedostaje provera i pokažite mi listu.

Dodajte stranicu /admin samo za vlasnika, na kojoj vlasnik može da menja uloge članova. Sprečite uklanjanje ili degradiranje poslednjeg vlasnika, beležite svaku promenu uloge sa tim ko ju je napravio i kada, i neka krajnja tačka za promenu uloge odbije svakoga ko nije vlasnik.

Česte greške

• Provera uloga samo u front endu. API je i dalje otvoren za svakoga ko ga pozove.
• Veranje ID-jevima iz klijenta — userId ili role u telu zahteva umesto iz sesije.
• Upiti bez ograničenja koji dohvataju samo po ID-ju zapisa.
• Uloge proverene na stranicama, ali ne na API rutama, izvozima, preuzimanjima fajlova ili webhook-ovima.
• Administrator po adresi emaila tvrdo kodiran u kodu (if email === 'me@...'), što se lako zaboravi i teško menja.
• Previše uloga prerano, koje niko ne može da objasni posle šest meseci.
• Zastarele sesije: degradirani korisnik zadržava administratorska prava dok se ne odjavi. Proveravajte uloge iz baze, ili ih osvežavajte, za osetljive radnje.

Kontrolna lista za RBAC

• Tabela dozvola napisana običnim jezikom, granični slučajevi odlučeni
• Server zna korisnika iz sesije, nikada iz podataka zahteva
• Uloge sačuvane u bazi; korisnici ne mogu sami da ih menjaju
• Jedna centralna provera dozvola, podrazumevano odbijanje, korišćena u svakoj ruti
• Svaki upit ograničen na korisnikovu organizaciju ili vlasništvo
• Row-level security tamo gde pregledač može da dođe do baze
• Interfejs sakriva ono što korisnici ne mogu da rade (samo radi upotrebljivosti)
• Osetljive radnje se beleže
• Svaka uloga testirana, uključujući direktne API pozive i promenjene ID-jeve

Kontrola pristupa je jedna stavka na dužoj listi; kontrolna lista bezbednosti za aplikacije napravljene AI-jem pokriva ostalo. Ako pravite alat za sopstveno osoblje, kako napraviti interni alat pokazuje gde 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 provajdera za autentifikaciju i opisujete uloge, a agent ih povezuje u vaš kod i u Postgres bazu vašeg projekta (dodavanje prijave u aplikaciju). Mythex-ove sopstvene uloge u radnom prostoru, kao što su Owner i Member, kontrolišu ko može da menja vaše Mythex projekte, a ne ko može da koristi objavljenu aplikaciju. Koristite Plan mode da se dogovorite o tabeli dozvola pre gradnje, zatim koristite prompt za pregled iznad i testirajte svaku ulogu u Preview-u pre objavljivanja. Bezbednosni prompt-ovi iz dokumentacije su koristan sledeći korak.

Pitanja