Paano Magdagdag ng Role-Based Access Control (RBAC) sa Iyong App

Para magdagdag ng role-based access control, bigyan ang bawat user ng isa o higit pang role (halimbawa admin, editor, viewer), tukuyin kung aling mga aksyon ang puwedeng gawin ng bawat role, at i-check ang mga permiso sa server para sa bawat request — hindi lang sa pagtatago ng mga button. I-check din na ang record na ina-access ay kabilang sa account o team ng user. Magsimula sa ilang nakapirming role sa database mo, at mag-test sa pamamagitan ng pagsubok na abutin ang data ng ibang user nang direkta.

Authentication vs authorisation

Dalawang salitang madalas na napagkakamalan:

• Authentication ay sino ka? — ang pag-login. Tingnan ang paano magdagdag ng login sa app mo.
• Authorisation ay ano ang puwede mong gawin? — aling mga page, record at aksyon ang maaabot ng naka-log in na user.

Ang RBAC ang pinakakaraniwang paraan ng authorisation. Mahalaga ito: ayon sa Setyembre 2026, Broken Access Control ang #1 sa OWASP Top 10:2025, ang malawakang ginagamit na listahan ng pinakaseryosong panganib sa seguridad ng web application. Karaniwang pagkabigo ang pagbabasa ng mga user sa record ng iba sa pamamagitan ng pagpalit ng ID sa URL, o ang mga ordinaryong user na tumatawag sa admin-only na API route.

Pumili ng model

Sa praktika, pinagsasama ng karamihan ng app ang dalawang bagay: roles para sa uri ng aksyon na puwedeng gawin ng isang tao, at pagmamay-ari para sa mga record na puwede niyang aksyunan. Ang "Puwedeng i-edit ng editor ang mga post" ay patakaran sa role; ang "…mga post sa sarili niyang workspace" ay patakaran sa pagmamay-ari. Kailangan mo ang pareho.

Magsimula nang mas simple kaysa sa tingin mo. Ang admin, member at viewer ay sapat na para sa nakakagulat na dami ng app. Mas madaling hatiin ang isang role sa susunod kaysa kalasin ang sampung role na walang nakakaintindi.

Idisenyo ang mga role bago magsulat ng code

Isulat muna ang talaan ng permiso sa simpleng wika. Ito ang nagsisilbing spec para sa AI at test plan mo:

Pagpasyahan din ang mga kaso sa gilid: puwede bang umalis ang huling may-ari? Puwede bang alisin ng admin ang may-ari? Ano ang nakikita ng user na natanggal?

Hakbang-hakbang

1. Magkaroon muna ng gumaganang login

Nakapatong ang RBAC sa authentication. Dapat maaasahang malaman ng server kung sino ang gumagawa ng bawat request, mula sa session o na-verify na token — hindi kailanman mula sa user ID na ipinadala ng browser sa request body.

2. I-store ang mga role sa database

Para sa app na iisang team lang, sapat ang role column sa users. Para sa mga team, gumamit ng memberships table:

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

Huwag hayaang baguhin ng mga user ang sarili nilang role sa karaniwang profile update. Ang pagbabago ng role ay dapat dumaan sa nakalaang endpoint na may check ng permiso.

3. I-check ang mga permiso sa server, sa iisang lugar

Sumulat ng isang helper — halimbawa can(user, 'projects.delete', project) — at tawagin ito sa bawat API route, server action at background task na bumabasa o nagbabago ng data. Mas madaling suriin at i-test ang iisang sentral na function kaysa mga check na nakakalat sa code. Deny by default: kung walang patakarang nagpapahintulot sa aksyon, tinatanggihan ito.

4. Sakupin ang bawat query

Dapat isama ng bawat query para sa data ng team ang team: where organization_id = :currentOrg, hindi lang where id = :id. Ito ang pumipigil sa isang tao na palitan ang /projects/123 ng /projects/124 at makita ang proyekto ng ibang kumpanya. Ibalik ang "not found" sa halip na "forbidden" para sa mga record ng ibang team, para hindi mo maipakitang umiiral sila.

5. Magdagdag ng proteksyon sa antas ng database kung saan ito mahalaga

Hinahayaan ng Postgres row-level security (RLS) ang database na ipatupad kung aling mga row ang nakikita ng bawat user. Mahalaga ito kapag direktang nakikipag-usap ang browser sa database (gaya ng ilang hosted na backend), at kapaki-pakinabang na pangalawang layer para sa mga sensitibong table kung hindi.

6. Ipakita ang mga role sa interface

Ngayon itago o i-disable ang mga hindi puwedeng gawin ng user, para hindi nakakalito ang app. Para sa kaginhawaan lamang ito; ang mga check sa server ang tunay na nagpoprotekta.

7. I-log ang mga sensitibong aksyon

Itala kung sino ang nagbago ng role, nagbura ng data o nag-export ng record, at kailan. Nakakatulong ang audit log sa mga tanong ng support at sa mga insidente.

8. Mag-test na parang attacker

Mag-login bilang bawat role at subukan ang bawat aksyon sa talaan ng permiso. Pagkatapos, subukan ang mga bagay na hindi dapat gumana: tumawag ng admin API route bilang viewer, palitan ang mga ID sa URL at request, alisin ang sarili bilang huling may-ari. Sulit sumulat ng automated na test para sa talaan ng permiso kapag tumatag na ang mga patakaran.

Mga prompt na gumagana

Magdagdag ng role-based access control. Mga role kada organisasyon: owner, admin, member, viewer, na nakaimbak sa memberships table. Ang mga permiso ay nasa talahanayang ito: [i-paste ang talaan mo]. Gumawa ng isang server-side na can(user, action, resource) helper, deny by default, at gamitin ito sa bawat API route. I-scope ang bawat query gamit ang organization_id. Itago sa UI ang mga aksyong hindi kayang gawin ng user, pero huwag kailanman umasa roon para sa seguridad.

Suriin ang bawat API route at server function sa app na ito. Para sa bawat isa, ilista kung anong data ang binabasa o binabago nito, kung tinitingnan nitong naka-log in ang user, kung tinitingnan nito ang role niya, at kung sakop ng query ang organisasyon niya. Ayusin ang anumang kulang ang check, at ipakita sa akin ang listahan.

Magdagdag ng admin-only na /admin page kung saan mababago ng owner ang mga role ng mga miyembro. Pigilan ang pag-alis o pagbaba ng huling owner, itala ang bawat pagbabago ng role kasama kung sino ang gumawa at kailan, at tiyaking tinatanggihan ng role-change endpoint ang sinumang hindi owner.

Mga karaniwang pagkakamali

• Pag-check ng role sa frontend lang. Bukas pa rin ang API sa sinumang tatawag dito.
• Pagtitiwala sa mga ID mula sa client — ang userId o role sa request body sa halip na sa session.
• Mga hindi naka-scope na query na kumukuha ng record sa pamamagitan lamang ng record ID.
• Naka-check ang role sa mga page pero hindi sa API route, export, file download o webhook.
• Admin ayon sa email address na naka-hard-code sa code (if email === 'me@...'), na madaling makalimutan at mahirap baguhin.
• Masyadong maraming role nang maaga, na walang makapagpapaliwanag pagkalipas ng anim na buwan.
• Lipas na session: ang na-demote na user ay nananatiling may admin rights hanggang mag-logout. I-check ang role mula sa database, o i-refresh ito, sa mga sensitibong aksyon.

Checklist ng RBAC

• Naisulat sa simpleng wika ang talaan ng permiso, at napagpasyahan ang mga kaso sa gilid
• Alam ng server ang user mula sa session, hindi mula sa request data
• Nasa database ang mga role; hindi maaaring baguhin ng mga user ang sarili nila
• Iisang sentral na check ng permiso, deny by default, ginagamit sa bawat route
• Bawat query ay nakasakop sa organisasyon o pagmamay-ari ng user
• Row-level security kung saan maaabot ng browser ang database
• Itinatago ng UI ang hindi kayang gawin ng user (para sa kaginhawaan lamang)
• Nilo-log ang mga sensitibong aksyon
• Nasubukan ang bawat role, kasama ang direktang API call at mga pinalitang ID

Isa lang ang access control sa mas mahabang listahan; sakop ng security checklist para sa mga app na ginawa gamit ang AI ang iba pa. Kung gumagawa ka ng tool para sa sarili mong staff, ipinapakita ng paano gumawa ng internal tool kung saan nababagay ang mga role.

RBAC sa Mythex

Wala kang makukuhang built-in na sistema ng login o roles para sa mga user ng app mo sa Mythex. Pumipili ka ng auth library o provider at inilalarawan ang mga role, at ikinakabit ng agent ang mga ito sa code mo at sa Postgres database ng project (idagdag ang login sa app mo). Ang mga workspace role ng Mythex mismo, gaya ng Owner at Member, ang nagkokontrol kung sino ang puwedeng mag-edit ng mga project mo sa Mythex, hindi kung sino ang puwedeng gumamit ng app na na-publish mo. Gamitin ang Plan mode para pagkasunduan ang talaan ng permiso bago gumawa, tapos gamitin ang prompt ng review sa itaas at subukan ang bawat role sa Preview bago mag-publish. Kapaki-pakinabang na susunod na hakbang ang security prompts sa docs.

Mga tanong