Cybersecurity glossary
What is Role-Based Access Control (RBAC)?
Learn what Role-Based Access Control (RBAC) is, how roles map users to permissions, how it differs from ABAC, and how to design RBAC without dangerous over-privilege.
Definition
Role-Based Access Control (RBAC) is an authorization model that assigns users to roles and grants permissions to those roles, so access decisions are based primarily on a principal’s role membership rather than on individual per-user permission lists.
Why RBAC matters
Authorization at scale cannot mean editing permissions for every person individually. Role-Based Access Control (RBAC) groups permissions into roles that match job functions—support agent, billing admin, read-only auditor—then assigns people to those roles.
RBAC is widely understood and easy to explain. It fails when roles become catch-all admin buckets or when applications check roles in the UI but not on every API.
How RBAC works
Define permissions
List actions on resources: read invoice, refund payment, manage users.
Compose roles
Bundle permissions into roles that mirror real job functions.
Assign users to roles
Grant membership based on hiring, team changes, and least privilege.
Authenticate the principal
Establish identity before evaluating role membership.
Enforce on every request
Server-side checks confirm the caller’s roles allow the requested action.
Review and revoke
Periodic access reviews remove unused roles and standing privilege.
RBAC vs ABAC vs ACLs
| Property | RBAC | ABAC | ACL |
|---|---|---|---|
| Primary input | Role membership | Attributes + policy | Per-object principal lists |
| Best fit | Stable job functions | Contextual/data-dependent rules | Collaborative sharing exceptions |
| Common failure | Role explosion / overbroad roles | Complex opaque policies | Drift across many objects |
Design pitfalls
God roles
A single admin role that can do everything becomes a breach multiplier.
UI-only checks
Hiding buttons while APIs accept the action is not authorization.
Standing privilege
Permanent elevation replaces safer just-in-time admin access.
Missing object scope
Roles without tenant/ownership checks enable horizontal data access.
Implementation checklist
- Map roles to job functions with least privilege; avoid catch-all admin packs.
- Enforce role checks on every API and admin path, not only in frontends.
- Combine RBAC with object-level and tenant checks for multi-user data.
- Use temporary elevation and MFA for privileged roles.
- Review role memberships on a schedule and on team changes.
- Log authorization denials and privileged allow decisions.
- Prevent privilege accumulation by cleaning unused roles automatically where possible.
- Document role meanings so auditors and engineers share the same vocabulary.
The practical takeaway
RBAC authorizes users through role membership and role permissions. It scales human access management when roles stay few, clear, and least-privileged.
Enforce roles on the server, scope them to tenants and objects, and review memberships. RBAC is a foundation—often paired with ABAC—not a guarantee that every object access is safe.
Related security terms
Attribute-Based Access Control (ABAC)
A complementary model that evaluates attributes and context beyond roles alone.
Privilege Escalation
Often enabled by overly broad roles or missing enforcement of role checks.
Broken Authentication
Identity issues that precede authorization; RBAC assumes authenticated principals.
Insecure Direct Object Reference (IDOR)
Object-level failures that roles alone do not fix without per-object checks.
Frequently asked questions
What is RBAC in simple terms?
RBAC gives permissions to roles like admin, editor, or viewer, then assigns people to those roles. Users inherit the permissions of the roles they hold.
How is RBAC different from ABAC?
RBAC centers on role membership. ABAC evaluates broader attributes of users, resources, actions, and environment. Many systems use RBAC for baseline access and ABAC for fine-grained rules.
What is role explosion?
Role explosion happens when organizations create too many specialized roles for every exception, making RBAC hard to understand and audit.
Does RBAC replace object-level authorization?
No. A role may allow reading invoices generally, but each request still needs checks that the user may access the specific invoice (ownership/tenant).
What are common RBAC mistakes?
Overly broad admin roles, unchecked privilege accumulation, roles assigned forever, and enforcing roles only in the UI.
How should teams design roles?
Start from job functions, apply least privilege, separate duties for sensitive actions, review memberships regularly, and prefer temporary elevation for admin tasks.
Is RBAC enough for multi-tenant SaaS?
RBAC helps, but tenant isolation and object-level checks remain mandatory. Roles should be scoped within a tenant boundary.
References
Explore authoritative guidance and frameworks related to role-based access control (rbac).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.