Како да додадете контрола на пристап според улоги (RBAC) во вашата апликација

За да додадете контрола на пристап според улоги, на секој корисник дајте една или повеќе улоги (на пример администратор, уредник, читач), дефинирајте кои дејства смее да ги прави секоја улога и проверете ги тие дозволи на серверот за секое барање — не само со скривање на копчиња. Проверете и дали записот до кој се пристапува му припаѓа на сметката или тимот на корисникот. Почнете со неколку фиксни улоги во вашата база на податоци и тестирајте со обид да пристапите до туѓи податоци директно.

Автентикација наспрема авторизација

Две зборови што често се мешаат:

• Автентикација е кој си ти? — најава. Видете како да додадете најава во апликацијата.
• Авторизација е што смееш да правиш? — до кои страници, записи и дејства има пристап најавениот корисник.

RBAC е најчестиот начин за авторизација. Важно е: од септември 2026, Broken Access Control е на прво место во OWASP Top 10:2025, широко користената листа на најсериозните безбедносни ризици за веб-апликации. Типични пропусти се корисници што ги читаат туѓите записи со промена на ID во URL-то или обични корисници што ги повикуваат API рутите само за администратори.

Изберете модел

Во пракса, повеќето апликации комбинираат две работи: улоги за тоа каков вид дејства може некој да прави, и сопственост за тоа на кои записи може да ги направи. „Уредниците можат да уредуваат постови“ е правило на улога; „…постови во нивниот работен простор“ е правило на сопственост. Ви требаат и двете.

Почнете поедноставно отколку што мислите. Администратор, член и читач покриваат изненадувачки многу апликации. Полесно е подоцна да се подели една улога, отколку да се разплетат десет улоги што никој не ги разбира.

Дизајнирајте ги улогите пред да пишувате код

Прво напишете табела со дозволи на јасен јазик. Таа служи и како спецификација за AI и како план за тестирање:

Одлучете и граничните случаи: може ли последниот сопственик да напушти? Може ли администратор да го отстрани сопственикот? Што гледа отстранетиот корисник?

Чекор по чекор

1. Прво имајте функционална најава

RBAC е над автентикацијата. Серверот мора сигурно да знае кој го прави секое барање, од сесија или верификуван токен — никогаш од ID на корисник што го испраќа прелистувачот во телото на барањето.

2. Чувајте ги улогите во базата на податоци

За апликација за еден тим, колона role на корисниците е во ред. За тимови, користете табела со членства:

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

Никогаш не дозволувајте корисниците сами да си ја поставуваат улогата преку обично ажурирање на профилот. Промените на улогите минуваат преку посебна крајна точка со проверка на дозволите.

3. Проверувајте ги дозволите на серверот, на едно место

Напишете еден помошник — нешто како can(user, 'projects.delete', project) — и повикувајте го во секоја API рута, серверско дејство и позадинска задача што чита или менува податоци. Една централна функција полесно се прегледува и тестира од проверки расфрлани низ кодот. Одбивајте по стандард: ако ниедно правило не дозволува дејство, тоа се одбива.

4. Ограничете секое барање

Секое барање за податоците на тимот треба да го вклучува тимот: where organization_id = :currentOrg, а не само where id = :id. Тоа го спречува некој да смени /projects/123 во /projects/124 и да види туѓ проект од друга компанија. За записи во други тимови, вратете „не е пронајдено“ наместо „забрането“, за да не откриете дека постојат.

5. Додајте заштита на ниво на база таму каде е важно

Row-level security (RLS) во Postgres ја наметнува на базата кои редови може да ги види секој корисник. Е неопходна ако прелистувачот разговара директно со базата (како кај некои хостирани backend-и), а корисен втор слој за чувствителни табели во спротивно.

6. Прикажете ги улогите во интерфејсот

Сега скријте или оневозможете го она што корисниците не смеат да го прават, за апликацијата да не биде збунувачка. Ова е само за употребливост; заштитата ја даваат проверките на серверот.

7. Евидентирајте ги чувствителните дејства

Записувајте кој ги менувал улогите, бришел податоци или извезувал записи, и кога. Евиденцијата на ревизија помага кај прашањата на поддршката и инцидентите.

8. Тестирајте како напаѓач

Најавете се како секоја улога и пробајте го секое дејство од табелата со дозволи. Потоа пробајте го она што не смее да работи: повикајте админ API рути како читач, менувајте ID-а во URL-а и барањата, отстранете се себеси како последен сопственик. Автоматски тестови за табелата со дозволи вреди да се напишат кога правилата ќе се стабилизираат.

Упатства што функционираат

Додај контрола на пристап според улоги. Улоги по организација: сопственик, администратор, член, читач, чувани во табела со членства. Дозволите се во оваа табела: [залепете ја вашата табела]. Создај една серверска функција can(user, action, resource), одбивај по стандард и користи ја во секоја API рута. Ограничувај секое барање по organization_id. Скривај ги дејствата што корисникот не може да ги направи во интерфејсот, но никогаш не се потпирај на тоа за безбедност.

Прегледај ја секоја API рута и серверска функција во апликацијата. За секоја, наведи какви податоци чита или менува, дали проверува дека корисникот е најавен, дали ја проверува неговата улога и дали го ограничува барањето на неговата организација. Поправи ги оние каде недостасува проверка и покажи ми ја листата.

Додај админ-only страница /admin каде сопственикот може да ги менува улогите на членовите. Спречи отстранување или деградирање на последниот сопственик, евидентирај секоја промена на улога со тоа кој ја направил и кога, и осигурај се дека крајната точка за промена на улоги ги одбива сите што не се сопственици.

Чести грешки

• Проверка на улогите само во фронтендот. API-то сè уште е отворено за секој што ќе го повика.
• Верување на ID-а од клиентот — userId или role во телото на барањето наместо во сесијата.
• Барања без ограничување што земаат запис по ID.
• Улогите проверени на страниците, но не и на API рутите, извозите, преземањата на датотеки или webhook-овите.
• Админ по е-пошта напишана тврдо во кодот (if email === 'me@...'), што лесно се заборава и тешко се менува.
• Премногу улоги прерано, што никој не може да ги објасни шест месеци подоцна.
• Застарени сесии: деградиран корисник задржува админ права додека не се одјави. Проверувајте ги улогите од базата, или освежете ги, при чувствителни дејства.

Контролна листа за RBAC

• Табелата со дозволи е напишана на јасен јазик, граничните случаи се одлучени
• Серверот го знае корисникот од сесијата, никогаш од податоците во барањето
• Улогите се чуваат во базата; корисниците не можат сами да ги менуваат
• Една централна проверка на дозволи, одбивање по стандард, користена во секоја рута
• Секое барање ограничено на организацијата или сопственоста на корисникот
• Row-level security таму каде прелистувачот може да дојде до базата
• Интерфејсот ги скрива дејствата што корисниците не можат да ги прават (само за употребливост)
• Чувствителните дејства се евидентирани
• Секоја улога е тестирана, вклучувајќи директни API повици и променети ID-а

Контролата на пристап е една ставка од подолга листа; контролната листа за безбедност за апликации направени со AI ги опфаќа останатите. Ако градите алатка за вашите вработени, како да направите внатрешна алатка покажува каде се вклопуваат улогите.

RBAC на Mythex

Mythex не обезбедува вграден систем за најава или улоги за корисниците на вашата апликација. Вие избирате библиотека или давател за автентикација и ги опишувате улогите, а агентот ги поврзува во вашиот код и во Postgres базата на проектот (додавање најава во апликацијата). Улогите во работниот простор на Mythex, како Сопственик и Член, контролираат кој може да ги уредува вашите проекти на Mythex, а не кој може да ја користи објавената апликација. Користете режим Plan за да се договорите за табелата со дозволи пред градењето, потоа користете го горенаведеното упатство за преглед и тестирајте ја секоја улога во Preview пред да објавите. Безбедносните упатства во документацијата се корисен следен чекор.

Прашања