What is role-based access control (RBAC)?
How an app decides that an editor can publish but a viewer cannot, without a rule for every person.
In short
Role-based access control (RBAC) is a way of managing permissions in which rights are granted to roles, such as owner, admin, editor or viewer, and people are given roles. Changing what a role may do changes it for everyone in that role, without editing each person one by one.
Also called: RBAC, Role-based security, User roles and permissions
Why does RBAC become urgent with the first business customer?
Prototypes often have two kinds of user: the founder, who can do everything, and everyone else. The first business customer asks for more: an admin who manages the team, members who work, a viewer from finance. If roles are bolted on as checks scattered through the interface, some screen or endpoint will always be missed.
How does RBAC put least privilege into practice?
NIST defines least privilege as restricting access to the minimum needed to do the task. RBAC is how you apply it at scale: start each role with nothing and grant what it needs. Enforce the role on the server or in the database, never only by hiding buttons, and record changes to roles in an audit log.
What does a simple RBAC model look like in practice?
A simple RBAC model has three parts: a list of permissions, a list of roles, and a table saying which person holds which role. Each role is a named bundle of permissions. Code never asks who a person is; it asks whether their role holds the permission the action needs.
| Permission | Owner | Admin | Editor | Viewer |
|---|---|---|---|---|
| View projects | Yes | Yes | Yes | Yes |
| Edit projects | Yes | Yes | Yes | No |
| Invite and remove people | Yes | Yes | No | No |
| Change billing | Yes | No | No | No |
When finance asks for read access, you give that person the viewer role. No new rule is written for them, and if viewers later need to export reports, one change covers everyone with the role.
How do you add roles to a Supabase or Lovable app?
Supabase documents a pattern for RBAC: store roles in a user_roles table and each role's permissions in a role_permissions table. A custom access token hook adds the user's role to their session token, and an authorize function checks it inside row-level security policies, so the database itself refuses actions a role does not hold.
- 01Model the rolesCreate the roles and permissions tables, scoped per organization if people belong to more than one.
- 02Put the role in the tokenEnable a custom access token hook under Authentication, Hooks, so each session carries a role claim.
- 03Check it in policiesWrite RLS policies that call a function such as authorize('projects.delete').
- 04Mirror it in the interfaceHide buttons a role cannot use, as a convenience only. The database stays the real check.
What are the most common RBAC mistakes?
Three mistakes cause most RBAC failures: checking roles in the interface but not on the server, giving people one global role when they belong to several organizations, and letting an admin role quietly accumulate every permission ever added, which OWASP calls privilege creep and advises reviewing for after launch.
- Roles checked in the interface but not on the server. OWASP is plain that apps must never rely on client-side access checks.
- One global role when people belong to several organizations.
- An admin role that quietly accumulates every permission ever added. OWASP calls this privilege creep and advises reviewing for it after launch.
If roles in your AI-built app live only in the interface, that is the kind of gap our vibe-coding rescue work starts with.
Common questions
What is the difference between RBAC and ABAC?
RBAC grants rights by role. Attribute-based access control (ABAC) decides from attributes of the user, the data and the situation, such as department or time of day. Many apps combine the two: roles for the broad rules, attributes such as ownership for record-level checks.
Where should roles be checked in a web app?
On the server or in the database, on every request. Hiding a button stops nobody who calls the API directly. OWASP's authorization guidance says apps must never rely on client-side access control checks. The interface can mirror the rules, but only as a convenience.
How many roles should a new SaaS app start with?
As few as the product needs, usually an owner or admin, a member and sometimes a read-only viewer. Each extra role is another set of rules to test. Start each role with no rights and add only what it needs, which is NIST's least privilege idea.
Can RBAC be done with Supabase row-level security?
Yes. Supabase documents storing roles in tables, adding the role to the session token with a custom access token hook, and checking it in row-level security policies through an authorize function. The database then refuses actions a role lacks, even if the interface misses a check.
Go deeper
Lovable authentication and secure user rolesHow to add sign-in and user roles to a Lovable app safely: where roles must live, how to protect admin areas, Google sign-in, MFA, and how to test it all.
Related terms
Sources
- NIST: Role Based Access Control project
- NIST glossary: least privilege
- Supabase docs: Custom Claims and Role-based Access Control
- OWASP Authorization Cheat Sheet
Sources checked October 24, 2026
More on this: Production architecture & security · All glossary terms
Built something in Lovable you want people to rely on?
We are the engineers who take it the rest of the way — secured, tested, released and supported.
