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, rather than being granted rights one by one. Changing what a role may do changes it for everyone in that role. It is the most common authorization model in business software.
Also called: RBAC, Role-based security, User roles and permissions
Why it matters when your prototype goes to production
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.
Least privilege
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.
Common pitfalls
- Roles checked in the interface but not on the server.
- One global role when people belong to several organisations.
- An admin role that quietly accumulates every permission ever added.
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.
Related terms
Sources
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.