Как да добавите контрол на достъпа на базата на роли (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 маршрут, server action и фонова задача, която чете или променя данни. Една централна функция е по-лесна за преглед и тестване от проверки, разпръснати из кода. Отказвайте по подразбиране: ако никое правило не разрешава действието, то се отхвърля.

4. Ограничавайте всяка заявка

Всяка заявка за данни на екипа трябва да включва екипа: where organization_id = :currentOrg, а не само where id = :id. Точно това спира някого да промени /projects/123 на /projects/124 и да види чужд проект. За записи в други екипи връщайте „не е намерено“, а не „забранено“, за да не разкривате, че съществуват.

5. Добавете защита на ниво база данни там, където е важно

Postgres row-level security (RLS) позволява на базата данни да налага кои редове може да вижда всеки потребител. Той е задължителен, ако браузърът говори директно с базата данни (както при някои хоствани бекенди), и полезен втори слой за чувствителните таблици в останалите случаи.

6. Отразете ролите в интерфейса

Сега скрийте или деактивирайте това, което потребителите не могат да правят, за да е ясно приложението. Това е само за удобство; защитават сървърните проверки.

7. Записвайте чувствителните действия

Записвайте кой е сменил роли, изтрил данни или експортирал записи и кога. Журналът на одита помага при въпроси от поддръжката и при инциденти.

8. Тествайте като нападател

Влизайте като всяка роля и опитайте всяко действие от таблицата с правата. После опитайте нещата, които не трябва да работят: извикайте административен API маршрут като читател, променете ID-та в URL адреси и заявки, премахнете себе си като последен собственик. Автоматичните тестове за таблицата с правата си струва да се напишат, след като правилата се установят.

Подсказки, които работят

Добави контрол на достъпа на базата на роли. Роли за всяка организация: owner, admin, member, viewer, съхранени в таблица с членства. Правата са в тази таблица: [постави таблицата си]. Създай една сървърна помощна функция can(user, action, resource), която отказва по подразбиране, и я използвай във всеки API маршрут. Ограничавай всяка заявка по organization_id. Скривай в интерфейса действията, които потребителят не може да извърши, но никога не разчитай на това за сигурност.

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

Добави страница /admin, достъпна само за администратори, където собственикът може да сменя ролите на членовете. Не позволявай премахване или понижаване на последния собственик, записвай всяка промяна на роля с това кой я е направил и кога, и увери се, че крайната точка за промяна на роли отхвърля всеки, който не е собственик.

Чести грешки

• Проверка на ролите само във фронтенда. API-то пак е отворено за всеки, който го извика.
• Доверие в ID-та от клиента — userId или role в тялото на заявката вместо от сесията.
• Заявки без ограничение, които извличат по ID на запис без друго условие.
• Роли, проверявани на страниците, но не и на API маршрутите, експортите, изтеглянията на файлове или webhooks.
• Администратор по имейл адрес, записан твърдо в кода (if email === 'me@...') — лесно е да се забрави и трудно се променя.
• Твърде много роли твърде рано, които никой не може да обясни след шест месеца.
• Остарели сесии: понижен потребител запазва администраторските права, докато не излезе. Проверявайте ролите в базата данни или ги обновявайте при чувствителни действия.

Контролен списък за RBAC

• Таблицата с правата е написана на обикновен език, граничните случаи са решени
• Сървърът знае потребителя от сесията, никога от данните в заявката
• Ролите се съхраняват в базата данни; потребителите не могат да сменят собствените си
• Една централна проверка на правата, отказваща по подразбиране, използвана във всеки маршрут
• Всяка заявка е ограничена до организацията или собствеността на потребителя
• Row-level security там, където браузърът може да достигне базата данни
• Интерфейсът скрива какво потребителите не могат да правят (само за удобство)
• Чувствителните действия се записват
• Всяка роля е тествана, включително директни API заявки и променени ID-та

Контролът на достъпа е една точка от по-дълъг списък; контролният списък за сигурност на приложения, изградени с AI, обхваща останалото. Ако строите инструмент за собствените си служители, как да създадете вътрешен инструмент показва къде се вписват ролите.

RBAC в Mythex

Mythex не предоставя вграден вход или система с роли за потребителите на приложението ви. Избирате библиотека за автентикация или доставчик и описвате ролите, а агентът ги вписва в кода ви и в Postgres базата данни на проекта (добавяне на вход в приложението ви). Ролите ви в работното пространство на Mythex, като Owner и Member, контролират кой може да редактира проектите ви в Mythex, а не кой може да използва публикуваното приложение. Използвайте режима Plan, за да съгласувате таблицата с правата преди строене, след това използвайте подканата за преглед по-горе и тествайте всяка роля в Preview, преди да публикувате. Полезно продължение са подканите за сигурност в документацията.

Въпроси