Jak přidat do aplikace řízení přístupu podle rolí (RBAC)

Pro přidání řízení přístupu podle rolí dejte každému uživateli jednu nebo více rolí (například admin, editor, čtenář), určete, jaké akce která role smí provádět, a tato oprávnění kontrolujte na serveru u každého požadavku, ne jen skrýváním tlačítek. Kontrolujte také, že záznam, ke kterému se přistupuje, patří účtu nebo týmu uživatele. Začněte několika pevnými rolemi v databázi a otestujte, že se nedostanete k datům jiného uživatele přímým požadavkem.

Autentizace versus autorizace

Dvě slova, která se často pletou:

• Autentizace je otázka kdo jsi?, tedy přihlášení. Viz jak přidat přihlášení do aplikace.
• Autorizace je otázka co smíš dělat?, tedy které stránky, záznamy a akce přihlášený uživatel může použít.

RBAC je nejběžnější způsob autorizace. Je to důležité: podle stavu k září 2026 je Broken Access Control na prvním místě v OWASP Top 10:2025, což je široce používaný seznam nejzávažnějších bezpečnostních rizik webových aplikací. Typická selhání jsou uživatelé čtoucí záznamy jiných uživatelů změnou ID v adrese nebo běžní uživatelé volající API trasy vyhrazené adminům.

Zvolte model

V praxi většina aplikací kombinuje dvě věci: role pro to, jaký typ akcí může někdo provádět, a vlastnictví pro to, nad kterými záznamy je může provádět. Pravidlo „editoři mohou upravovat příspěvky“ je pravidlo podle role; „…příspěvky ve svém pracovním prostoru“ je pravidlo podle vlastnictví. Potřebujete obojí.

Začněte jednodušeji, než si myslíte. Admin, člen a čtenář pokryjí překvapivě mnoho aplikací. Roli je snazší později rozdělit, než rozmotat deset rolí, kterým nikdo nerozumí.

Navrhněte role dřív, než napíšete kód

Nejdřív sepište tabulku oprávnění srozumitelným jazykem. Poslouží jako zadání pro AI i jako plán testů:

Rozhodněte i okrajové případy: Může poslední vlastník odejít? Může admin odebrat vlastníka? Co uvidí odebraný uživatel?

Krok za krokem

1. Mějte nejdřív funkční přihlášení

RBAC stojí na autentizaci. Server musí spolehlivě vědět, kdo každý požadavek posílá, a to ze relace nebo ověřeného tokenu, nikdy z ID uživatele, které prohlížeč pošle v těle požadavku.

2. Ukládejte role v databázi

Pro aplikaci s jedním týmem stačí sloupec role u uživatelů. Pro týmy použijte tabulku členství:

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

Nikdy nedovolte uživatelům nastavit si vlastní roli běžnou aktualizací profilu. Změny rolí musí jít přes samostatný koncový bod, který kontroluje oprávnění.

3. Kontrolujte oprávnění na serveru, na jednom místě

Napište jeden pomocný nástroj, něco jako can(user, 'projects.delete', project), a volejte ho v každé API trase, serverové akci a úloze na pozadí, které čte nebo mění data. Jedna centrální funkce se lépe kontroluje a testuje než kontroly roztroušené po kódu. Odmítejte ve výchozím stavu: pokud žádné pravidlo akci nepovolí, je zamítnuta.

4. Omezujte každý dotaz

Každý dotaz na data týmu má obsahovat tým: where organization_id = :currentOrg, nejen where id = :id. Tím zabráníte tomu, aby někdo změnil /projects/123 na /projects/124 a viděl projekt jiné firmy. U záznamů v jiných týmech vracejte „nenalezeno“ místo „zakázáno“, abyste neprozradili, že existují.

5. Přidejte ochranu na úrovni databáze tam, kde záleží

Row-level security (RLS) v Postgresu umožní databázi samotné vynutit, které řádky každý uživatel vidí. Je zásadní, pokud prohlížeč mluví s databází přímo (jako u některých hostovaných backendů), a jinak je užitečnou druhou vrstvou pro citlivé tabulky.

6. Odrazte role v rozhraní

Nyní skryjte nebo znepřístupněte to, co uživatelé nemohou dělat, aby aplikace nebyla matoucí. Je to jen pro použitelnost; chrání vás kontroly na serveru.

7. Zaznamenávejte citlivé akce

Zaznamenávejte, kdo změnil role, smazal data nebo exportoval záznamy, a kdy. Auditní záznam pomáhá s dotazy podpory a s incidenty.

8. Testujte jako útočník

Přihlaste se jako každá role a zkuste každou akci z tabulky oprávnění. Pak zkuste věci, které nemají fungovat: volejte administrátorské API trasy jako čtenář, měňte ID v adresách a požadavcích, odeberte sami sebe jako posledního vlastníka. Automatizované testy tabulky oprávnění stojí za to napsat, jakmile se pravidla ustálí.

Prompty, které fungují

Přidej řízení přístupu podle rolí. Role pro každou organizaci: owner, admin, member, viewer, uložené v tabulce memberships. Oprávnění jsou v této tabulce: [vlož svou tabulku]. Vytvoř jeden serverový pomocný nástroj can(user, action, resource), který odmítá ve výchozím stavu, a použij ho v každé API trase. Každý dotaz omez na organization_id. Akce, které uživatel nemůže provést, skryj v rozhraní, ale nikdy se na to nespoléhej kvůli bezpečnosti.

Projdi každou API trasu a serverovou funkci v této aplikaci. U každé vypiš, jaká data čte nebo mění, zda kontroluje, že je uživatel přihlášen, zda kontroluje jeho roli a zda omezuje dotaz na jeho organizaci. Doplň chybějící kontroly a ukaž mi seznam.

Přidej stránku /admin přístupnou jen vlastníkovi, kde může měnit role členů. Zabraň odebrání nebo degradaci posledního vlastníka, zaznamenávej každou změnu role s tím, kdo ji provedl a kdy, a ujisti se, že koncový bod pro změnu rolí odmítne každého, kdo není vlastník.

Časté chyby

• Kontrola rolí jen ve frontendu. API je stále otevřené pro každého, kdo ho zavolá.
• Důvěřování ID z klienta, tedy userId nebo role v těle požadavku místo relace.
• Neomezené dotazy, které načítají podle samotného ID záznamu.
• Role kontrolované na stránkách, ale ne na API trasách, exportech, stahování souborů nebo webhookách.
• Admin podle e-mailu natvrdo zapsaný v kódu (if email === 'me@...'), na který se snadno zapomene a který se těžko mění.
• Příliš mnoho rolí příliš brzy, které po půl roce nikdo neumí vysvětlit.
• Zastaralé relace: degradovaný uživatel si podrží admin práva, dokud se neodhlásí. U citlivých akcí kontrolujte role v databázi nebo je obnovujte.

Kontrolní seznam RBAC

• Tabulka oprávnění sepsaná srozumitelným jazykem, okrajové případy rozhodnuty
• Server pozná uživatele podle relace, nikdy podle dat z požadavku
• Role jsou uložené v databázi; uživatelé si je nemohou měnit sami
• Jedna centrální kontrola oprávnění, odmítání ve výchozím stavu, použitá v každé trase
• Každý dotaz omezen na organizaci nebo vlastnictví uživatele
• Řádková bezpečnost tam, kde se prohlížeč může dostat k databázi
• Rozhraní skrývá to, co uživatelé nemohou dělat (jen pro použitelnost)
• Citlivé akce jsou zaznamenány
• Každá role otestována, včetně přímých volání API a změněných ID

Kontrola přístupu je jedna položka delšího seznamu; kontrolní seznam zabezpečení pro aplikace vytvořené s AI pokrývá zbytek. Pokud stavíte nástroj pro vlastní zaměstnance, ukazuje jak vytvořit interní nástroj, kam role patří.

RBAC v Mythexu

Mythex pro uživatele vaší aplikace neposkytuje vestavěný systém přihlášení ani rolí. Vyberete si knihovnu nebo poskytovatele autentizace a popíšete role; agent je zapojí do vašeho kódu a do Postgres databáze projektu (přidání přihlášení do aplikace). Role pracovního prostoru v Mythexu, například Owner a Member, řídí, kdo může upravovat vaše projekty v Mythexu, ne kdo smí používat publikovanou aplikaci. Před stavbou použijte režim plánu, abyste se dohodli na tabulce oprávnění, a pak použijte výše uvedený kontrolní prompt a před publikováním otestujte každou roli v Preview. Dokumentace obsahuje užitečné bezpečnostní prompty jako navazující krok.

Otázky