Kako dodati kontrolu pristupa temeljenu na ulogama (RBAC) u svoju aplikaciju

Za dodavanje kontrole pristupa temeljene na ulogama svakom korisniku dodijelite jednu ili više uloga (primjerice administrator, urednik, čitatelj), definirajte koje radnje svaka uloga smije obavljati i te dozvole provjeravajte na poslužitelju za svaki zahtjev, a ne samo skrivanjem gumbova. Također provjerite pripada li zapis kojem se pristupa korisnikovu računu ili timu. Počnite s nekoliko fiksnih uloga u bazi podataka i testirajte tako da pokušate doći do tuđih podataka izravno.

Autentifikacija i autorizacija

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

• Autentifikacija je tko si ti?, odnosno prijava. Pogledajte kako dodati prijavu u aplikaciju.
• Autorizacija je što smiješ raditi?, odnosno do kojih stranica, zapisa i radnji prijavljeni korisnik može doći.

RBAC je najčešći način autorizacije. Važno je: od rujna 2026., Broken Access Control je na prvom mjestu u OWASP Top 10:2025, široko korištenom popisu najozbiljnijih sigurnosnih rizika web aplikacija. Tipični propusti su korisnici koji čitaju tuđe zapise mijenjanjem ID-ja u URL-u ili obični korisnici koji pozivaju API rute namijenjene samo administratorima.

Odaberite model

U praksi većina aplikacija kombinira dvije stvari: uloge za to kakve radnje netko smije poduzeti i vlasništvo za to nad kojim zapisima ih smije poduzeti. „Urednici mogu uređivati objave” je pravilo uloge; „…objave u vlastitom radnom prostoru” je pravilo vlasništva. Trebate oboje.

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

Osmislite uloge prije pisanja koda

Najprije napišite tablicu dozvola običnim jezikom. Ona je ujedno specifikacija za AI i vaš plan testiranja:

Odlučite i rubne slučajeve: može li zadnji vlasnik napustiti tim? Može li administrator ukloniti vlasnika? Što uklonjeni korisnik vidi?

Korak po korak

1. Najprije imajte ispravnu prijavu

RBAC leži na vrhu autentifikacije. Poslužitelj mora pouzdano znati tko šalje svaki zahtjev, iz sesije ili provjerenog tokena, a nikada iz ID-ja korisnika koji preglednik šalje u tijelu zahtjeva.

2. Spremite uloge u bazu podataka

Za aplikaciju jednog tima stupac role na korisnicima je dovoljan. Za timove koristite tablicu č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 dopustite korisnicima da sami postave svoju ulogu kroz običnu izmjenu profila. Promjene uloga idu kroz namjenski krajnju točku s provjerom dozvola.

3. Provjeravajte dozvole na poslužitelju, na jednom mjestu

Napišite jednu pomoćnu funkciju, nešto poput can(user, 'projects.delete', project), i pozovite je u svakoj API ruti, server akciji i pozadinskom zadatku koji čita ili mijenja podatke. Jedna središnja funkcija lakša je za pregled i testiranje nego provjere raspršene po kodu. Zadano odbijte: ako nijedno pravilo ne dopušta radnju, ona se odbija.

4. Ograničite svaki upit

Svaki upit za podatke tima treba uključiti tim: where organization_id = :currentOrg, a ne samo where id = :id. Time se sprečava da netko promijeni /projects/123 u /projects/124 i vidi tuđi projekt druge tvrtke. Za zapise drugih timova vratite „nije pronađeno” umjesto „zabranjeno”, kako ne biste otkrili da postoje.

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

Sigurnost na razini redaka (RLS) u Postgresu omogućuje bazi da provodi koje retke korisnik smije vidjeti. Bitna je ako preglednik izravno komunicira s bazom (kao kod nekih hostiranih backenda), a inače je koristan drugi sloj za osjetljive tablice.

6. Odražavajte uloge u sučelju

Sada skrijte ili onemogućite ono što korisnici ne smiju, kako aplikacija ne bi zbunjivala. To služi samo upotrebljivosti; zaštitu osiguravaju provjere na poslužitelju.

7. Bilježite osjetljive radnje

Bilježite tko je mijenjao uloge, brisao podatke ili izvozio zapise te kada. Revizijski dnevnik pomaže kod pitanja podrške i incidenata.

8. Testirajte kao napadač

Prijavite se kao svaka uloga i isprobajte svaku radnju iz tablice dozvola. Zatim probajte ono što ne bi smjelo raditi: pozovite administratorske API rute kao čitatelj, mijenjajte ID-jeve u URL-ovima i zahtjevima, uklonite sebe kao zadnjeg vlasnika. Automatizirane testove za tablicu dozvola vrijedi napisati kada se pravila ustale.

Upute koje dobro funkcioniraju

Dodaj kontrolu pristupa temeljenu na ulogama. Uloge po organizaciji: vlasnik, administrator, član, čitatelj, spremljene u tablici memberships. Dozvole su u ovoj tablici: [zalijepi svoju tablicu]. Napravi jednu poslužiteljsku funkciju can(user, action, resource), zadano odbijanje, i koristi je u svakoj API ruti. Ograniči svaki upit na organization_id. Sakrij radnje koje korisnik ne smije izvesti u sučelju, ali se nikada ne oslanjaj na to za sigurnost.

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

Dodaj stranicu /admin samo za vlasnika na kojoj vlasnik može mijenjati uloge članova. Spriječi uklanjanje ili degradiranje zadnjeg vlasnika, bilježi svaku promjenu uloge s time tko ju je napravio i kada te osiguraj da krajnja točka za promjenu uloga odbija svakoga tko nije vlasnik.

Česte greške

• Provjera uloga samo u frontendu. API je i dalje otvoren svakome tko ga pozove.
• Vjerovanje ID-jevima s klijenta, primjerice userId ili role u tijelu zahtjeva umjesto u sesiji.
• Neograničeni upiti koji dohvaćaju po samom ID-ju zapisa.
• Uloge provjerene na stranicama, ali ne na API rutama, izvozima, preuzimanjima datoteka ili webhookovima.
• Administrator po e-pošti tvrdo upisan u kod (if email === 'me@...'), što je lako zaboraviti i teško promijeniti.
• Previše uloga prerano, koje nitko ne može objasniti šest mjeseci kasnije.
• Zastarjele sesije: degradirani korisnik zadržava administratorska prava dok se ne odjavi. Provjeravajte uloge iz baze podataka ili ih osvježite pri osjetljivim radnjama.

Kontrolni popis za RBAC

• Tablica dozvola napisana običnim jezikom, rubni slučajevi odlučeni
• Poslužitelj zna korisnika iz sesije, nikada iz podataka zahtjeva
• Uloge su spremljene u bazi; korisnici ne mogu mijenjati svoje
• Jedna središnja provjera dozvola, zadano odbijanje, korištena u svakoj ruti
• Svaki upit ograničen na korisnikovu organizaciju ili vlasništvo
• Sigurnost na razini redaka tamo gdje preglednik može doći do baze
• Sučelje skriva ono što korisnici ne mogu raditi (samo radi upotrebljivosti)
• Osjetljive radnje se bilježe
• Svaka uloga testirana, uključujući izravne API pozive i promijenjene ID-jeve

Kontrola pristupa je jedna stavka na duljem popisu; kontrolni popis sigurnosti za aplikacije izrađene AI-jem pokriva ostalo. Ako gradite alat za vlastito osoblje, kako izraditi interni alat pokazuje gdje se uklapaju uloge.

RBAC na Mythexu

Mythex ne pruža ugrađeni sustav prijave ili uloga za korisnike vaše aplikacije. Odabirete biblioteku ili pružatelja autentifikacije i opisujete uloge, a agent ih povezuje s vašim kodom i Postgres bazom podataka projekta (dodavanje prijave u aplikaciju). Uloge Mythex radnog prostora, poput Vlasnika i Člana, kontroliraju tko može uređivati vaše Mythex projekte, a ne tko može koristiti objavljenu aplikaciju. Koristite način Plan da dogovorite tablicu dozvola prije izgradnje, zatim koristite gornju uputu za pregled i testirajte svaku ulogu u pregledu prije objave. Dokumentacijske sigurnosne upute su koristan sljedeći korak.

Pitanja